インデックス

  1 イントロダクション
   1.1 本ドキュメントの目的
   1.2 本ドキュメントの次に
   1.3 改訂履歴
   1.4 本ドキュメントの修正・改善
   1.5 例示したコードの説明
   1.6 本ドキュメントでの言葉の使い方の注意

  2 ソフトウェアプラクティス
   2.1 DRYの原則
    2.1.1 作業の繰り返し
    2.1.2 成果物の重複
   2.2 KISSの原則
   2.3 ボーイスカウトの規則
   2.4 YAGNIの原則
   2.5 Name and Conquer
   2.6 ノコギリの刃を研ぐ
   2.7 推定有罪
   2.8 デメテルの法則
   2.9 コンウェイの法則
   2.10 Inside-Outの原則
   2.11 SOLID

  3 プログラミング規約
   3.1 型とインスタンス
    3.1.1 算術型
     3.1.1.1 整数型
     3.1.1.2 char型
     3.1.1.3 std::byte型
     3.1.1.4 bool型
     3.1.1.5 浮動小数点型
    3.1.2 enum
    3.1.3 bit field
    3.1.4 class
    3.1.5 struct
    3.1.6 union
    3.1.7 配列
    3.1.8 型エイリアス
    3.1.9 const/constexprインスタンス
    3.1.10 リテラル
    3.1.11 型推論
     3.1.11.1 auto
    3.1.12 インスタンスの初期化
    3.1.13 rvalue
   3.2 クラスとインスタンス
    3.2.1 ファイルの使用方法
    3.2.2 クラスの規模
     3.2.2.1 行数
     3.2.2.2 メンバの数
     3.2.2.3 凝集度
    3.2.3 アクセスレベルと隠蔽化
    3.2.4 継承/派生
     3.2.4.1 インターフェースの継承
     3.2.4.2 多重継承
    3.2.5 非静的なメンバ変数/定数の初期化
    3.2.6 静的なメンバ変数/定数の初期化
    3.2.7 mutableなメンバ変数
    3.2.8 スライシング
    3.2.9 オブジェクトの所有権
    3.2.10 オブジェクトのライフタイム
   3.3 非メンバ関数/メンバ関数
    3.3.1 非メンバ関数
    3.3.2 メンバ関数
     3.3.2.1 特殊メンバ関数
     3.3.2.2 コンストラクタ
     3.3.2.3 copyコンストラクタ、copy代入演算子
     3.3.2.4 moveコンストラクタ、move代入演算子
     3.3.2.5 初期化子リストコンストラクタ
     3.3.2.6 デストラクタ
     3.3.2.7 オーバーライド
    3.3.3 非メンバ関数/メンバ関数共通
     3.3.3.1 サイクロマティック複雑度
     3.3.3.2 行数
     3.3.3.3 オーバーロード
     3.3.3.4 演算子オーバーロード
     3.3.3.5 実引数/仮引数
     3.3.3.6 自動変数
     3.3.3.7 戻り値型
     3.3.3.8 constexpr関数
     3.3.3.9 リエントラント性
     3.3.3.10 エクセプション処理
     3.3.3.11 ビジーループ
   3.4 構文
    3.4.1 複合文
    3.4.2 switch文
    3.4.3 if文
    3.4.4 範囲for文
    3.4.5 制御文のネスト
    3.4.6 return文
    3.4.7 goto文
    3.4.8 ラムダ式
    3.4.9 マクロの中の文
   3.5 演算子
    3.5.1 優先順位
    3.5.2 代入演算
    3.5.3 ビット演算
    3.5.4 論理演算
    3.5.5 三項演算子
    3.5.6 メモリアロケーション
     3.5.6.1 new
     3.5.6.2 delete
     3.5.6.3 メモリ制約が強いシステムでの::operator new
    3.5.7 sizeof
    3.5.8 ポインタ間の演算
    3.5.9 RTTI
    3.5.10 キャスト、暗黙の型変換
   3.6 プリプロセッサ命令
    3.6.1 関数型マクロ
    3.6.2 マクロ定数
   3.7 パッケージとその構成ファイル
    3.7.1 パッケージの実装と公開
    3.7.2 識別子の宣言、定義
    3.7.3 依存関係
    3.7.4 二重読み込みの防御
    3.7.5 ヘッダファイル内の#include
    3.7.6 #includeするファイルの順番
    3.7.7 #includeで指定するパス名
   3.8 スコープ
    3.8.1 スコープの定義と原則
    3.8.2 名前空間
    3.8.3 using宣言/usingディレクティブ
    3.8.4 ADLと名前空間による修飾の省略
    3.8.5 名前空間のエイリアス
   3.9 ランタイムの効率
    3.9.1 前置/後置演算子の選択
    3.9.2 operator X、operator x=の選択
    3.9.3 関数の戻り値オブジェクト
    3.9.4 move処理
    3.9.5 std::string vs std::string const& vs std::string_view
    3.9.6 extern template
   3.10 標準クラス、関数の使用制限
    3.10.1 STL
     3.10.1.1 スマートポインタの使用制限
     3.10.1.2 配列系コンテナクラスの使用制限
     3.10.1.3 std::stringの使用制限
     3.10.1.4 std::string_viewの使用制限
    3.10.2 POSIX系関数
     3.10.2.1 使用禁止関数一覧
     3.10.2.2 使用禁止関数の理由や注意点
      3.10.2.2.1 バッファオーバーランを引き起こしやすい関数
      3.10.2.2.2 コマンドインジェクション防止
      3.10.2.2.3 obsolete関数
      3.10.2.2.4 LEGACY関数
      3.10.2.2.5 スレッドセーフでない関数
      3.10.2.2.6 標準外関数等
      3.10.2.2.7 扱いが難しい関数
     3.10.2.3 典型的な注意点
      3.10.2.3.1 リソースリークを引き起こしやすい関数
      3.10.2.3.2 シンボリックリンクの検査
      3.10.2.3.3 strncpy(), strncat()の終端
      3.10.2.3.4 TOCTOU (Time Of Check, Time Of Use)
      3.10.2.3.5 メモリアロケーション
      3.10.2.3.6 非同期シグナル
   3.11 その他
    3.11.1 assertion
    3.11.2 アセンブラ
    3.11.3 言語拡張機能
   3.12 特に重要なプログラミング規約

  4 コード解析
   4.1 コンパイラによる静的解析
    4.1.1 g++の警告機能
    4.1.2 clang++の警告機能
   4.2 scan-buildによる静的解析
   4.3 cppcheck静的解析
   4.4 sanitizerによる動的解析
   4.5 まとめ

  5 コーディングスタイル
   5.1 インデント
    5.1.1 インデント用文字
    5.1.2 if、for、while、do-whileのインデント
    5.1.3 ブロックのインデント
    5.1.4 case、defaultのインデント
   5.2 ブロック(波括弧({}))
   5.3 関数シグネチャ内の’()’
   5.4 クラスのアクセスレベル
   5.5 スペース
    5.5.1 文の後
    5.5.2 コンマの後
    5.5.3 単項演算子、二項演算子、三項演算子の前後
    5.5.4 不要なブランク文字
   5.6 三項演算子のスタイル
   5.7 ポインタ型やリファレンス型インスタンスの宣言、定義の*や&の場所
   5.8 行数・桁数
    5.8.1 関数の行数
    5.8.2 行のカラム数
   5.9 ブロックの論理レベル
   5.10 名前空間
   5.11 clang-format

  6 命名規則
   6.1 禁止事項
    6.1.1 略語リスト
    6.1.2 言葉の対称性
   6.2 ファイル、ディレクトリの命名
    6.2.1 ファイル名
    6.2.2 ディレクトリ名
   6.3 識別子の命名
    6.3.1 型名
    6.3.2 定数名
    6.3.3 ローカル変数名(自動変数名、仮引数名、関数内static変数名)
    6.3.4 メンバ変数名
    6.3.5 メンバ関数名
    6.3.6 Accessorメンバ関数名
    6.3.7 関数名
    6.3.8 名前空間名
    6.3.9 テンプレート名
    6.3.10 テンプレートの仮引数名
    6.3.11 マクロ名
    6.3.12 その他の命名則

  7 コメント
   7.1 情報を付加しないコメント
   7.2 コメントのスタイル
    7.2.1 クラスのコメント
    7.2.2 関数のコメント
    7.2.3 enumのコメント
    7.2.4 型エイリアスのコメント
    7.2.5 template仮引数のコメント

  8 SOLID
   8.1 単一責任の原則(SRP)
   8.2 オープン・クローズドの原則(OCP)
   8.3 リスコフの置換原則(LSP)
   8.4 インターフェース分離の原則(ISP)
   8.5 依存関係逆転の原則(DIP)
   8.6 まとめ

  9 デザインパターン
   9.1 ガード節
   9.2 BitmaskType
   9.3 Pimpl
   9.4 Accessor
   9.5 Copy-And-Swap
   9.6 Immutable
   9.7 Clone(仮想コンストラクタ)
   9.8 NVI(non virtual interface)
   9.9 RAII(scoped guard)
   9.10 Future
   9.11 DI(dependency injection)
   9.12 Singleton
   9.13 State
   9.14 Null Object
   9.15 Templateメソッド
   9.16 Factory
   9.17 Named Constructor
   9.18 Proxy
   9.19 Strategy
   9.20 Visitor
   9.21 CRTP(curiously recurring template pattern)
   9.22 Observer
   9.23 MVC
   9.24 Cでのクラス表現

  10 アーキテクチャ
   10.1 アーキテクチャの定義
   10.2 アーキテクチャの設計
   10.3 アーキテクチャとファイル構造
   10.4 アーキテクチャの見直し
    10.4.1 パッケージが大きくなりすぎる
    10.4.2 当初、想定していない依存関係が必要になる
    10.4.3 コードクローンが避けられない
    10.4.4 当初、想定していない非同期処理が必要になる
   10.5 アーキテクチャの再構築
    10.5.1 アーキテクチャ再構築の準備
    10.5.2 アーキテクチャ再構築のチーム編成
    10.5.3 アーキテクチャ再構築の手順
     10.5.3.1 現在のソースコードをベースに再構築するかどうかを判断する
     10.5.3.2 パッケージ間の依存関係を整理する
     10.5.3.3 依存関係が整理されたパッケージ毎に単体テストを作る
     10.5.3.4 統合テストプログラムを作る
     10.5.3.5 単体テストや統合テストを自動実行できる環境を整える
     10.5.3.6 リファクタリングを行う
     10.5.3.7 まとめ

  11 開発プロセスとインフラ
   11.1 プロセス
    11.1.1 ウォーターフォールモデル、V字モデル
    11.1.2 アジャイル系プロセス
    11.1.3 ウォーターフォール vs アジャイル
   11.2 アジャイル系プロセスのプラクティスとインフラ
    11.2.1 自動単体テスト
     11.2.1.1 自動単体テストとは？
     11.2.1.2 単体テストのメリット
     11.2.1.3 アーキテクチャと単体テスト
     11.2.1.4 単体テストのサポートツール
    11.2.2 リファクタリング
     11.2.2.1 リファクタリングのための回帰テスト
     11.2.2.2 ソースコードの改善
     11.2.2.3 リファクタリングの例
      11.2.2.3.1 オリジナルのソースコード
      11.2.2.3.2 機能追加によるソースコード品質劣化
      11.2.2.3.3 小規模なリファクタリング
      11.2.2.3.4 構造のリファクタリング
      11.2.2.3.5 単体テストの開発
      11.2.2.3.6 クラスの導入
      11.2.2.3.7 単体テストの変更
      11.2.2.3.8 MVCの導入
      11.2.2.3.9 単体テストの変更(単体テスト用クラス導入)
      11.2.2.3.10 DIの導入
      11.2.2.3.11 全クラスの単体テスト
    11.2.3 自動統合テスト
     11.2.3.1 自動統合テストとは？
     11.2.3.2 自動統合テストのための仕様追加
     11.2.3.3 自動統合テストのためのソースコード変更
     11.2.3.4 自動統合テスト用ソースコード変更のための単体テスト
     11.2.3.5 自動統合テストの実装
    11.2.4 TDD
    11.2.5 CI(継続的インテグレーション)
     11.2.5.1 バージョン管理システム
      11.2.5.1.1 gitのブランチモデル
      11.2.5.1.2 コードインスペクション
     11.2.5.2 CIとは？
     11.2.5.3 CIとワークフロー
     11.2.5.4 CI項目実行の長時間化と分割
     11.2.5.5 CI項目の例
   11.3 まとめ

  12 並行処理
   12.1 ref_async_r5改善プログラムの要件
    12.1.1 Controller
    12.1.2 View
    12.1.3 Model
   12.2 非同期処理とその管理
    12.2.1 TwoPhaseTaskIF(TwoPhaseTaskPtr)
    12.2.2 Dispatcher
    12.2.3 TwoPhaseTaskPtrキュー管理機構
   12.3 ref_async_r6の構造
   12.4 まとめ

  13 テンプレートメタプログラミング
   13.1 ログ取得ライブラリの開発
    13.1.1 要件
    13.1.2 ログ取得ライブラリのインターフェース
    13.1.3 パラメータパック
     13.1.3.1 パラメータパックの畳みこみ式
     13.1.3.2 前から演算するパラメータパック
    13.1.4 Loggerの実装
    13.1.5 ユーザ定義型とそのoperator<<のname lookup
    13.1.6 Ints_tのログ登録
     13.1.6.1 operator<<をstd内で宣言する
     13.1.6.2 operator<<をグローバル名前空間内で宣言する
     13.1.6.3 operator<<をLogging内で宣言する
     13.1.6.4 Logging::Logger::set_inner(ints)内でusing namespace Appを行う
     13.1.6.5 Ints_tを構造体としてApp内に宣言する
     13.1.6.6 operator<<を使わない
     13.1.6.7 Ints_tのログ登録のまとめ
   13.2 Nstdライブラリの開発
    13.2.1 Nstdライブラリを使用したリファクタリング
    13.2.2 安全なvector
    13.2.3 安全な配列型コンテナ
    13.2.4 初期化子リストの副作用
   13.3 メタ関数のテクニック
    13.3.1 STLのtype_traits
     13.3.1.1 std::true_type/std::false_type
     13.3.1.2 std::integral_constant
     13.3.1.3 std::is_same
     13.3.1.4 std::enable_if
     13.3.1.5 std::conditional
     13.3.1.6 std::is_void
    13.3.2 is_void_xxxの実装
     13.3.2.1 is_void_fの実装
     13.3.2.2 is_void_sの実装
     13.3.2.3 is_void_sfinae_fの実装
     13.3.2.4 is_void_sfinae_sの実装
     13.3.2.5 is_void_ena_sの実装
     13.3.2.6 is_void_cond_sの実装
    13.3.3 is_same_xxxの実装
     13.3.3.1 is_same_fの実装
     13.3.3.2 is_same_vの実装
     13.3.3.3 is_same_sの実装
     13.3.3.4 is_same_sfinae_fの実装
     13.3.3.5 is_same_sfinae_sの実装
     13.3.3.6 is_same_templの実装
     13.3.3.7 IsSameSomeOfの実装
    13.3.4 AreConvertibleXxxの実装
     13.3.4.1 AreConvertibleの実装
     13.3.4.2 AreConvertibleWithoutNarrowConvの実装
    13.3.5 関数の存在の診断
     13.3.5.1 exists_void_func_sfinae_fの実装
     13.3.5.2 exists_void_func_sfinae_sの実装
     13.3.5.3 exists_void_func_sfinae_s2の実装
     13.3.5.4 exists_begin/exsits_endの実装
     13.3.5.5 IsRangeの実装
     13.3.5.6 exists_put_to_as_memberの実装
     13.3.5.7 exists_put_to_as_non_memberの実装
     13.3.5.8 ExistsPutToの実装
     13.3.5.9 ValueTypeの実装
   13.4 Nstdライブラリの開発2
    13.4.1 SafeArray2の開発
    13.4.2 Nstd::SafeIndexの開発
    13.4.3 Nstd::SafeIndexのoperator<<の開発
    13.4.4 コンテナ用Nstd::operator<<の開発
   13.5 ログ取得ライブラリの開発2
   13.6 その他のテンプレートテクニック
    13.6.1 ユニバーサルリファレンスとstd::forward
    13.6.2 ジェネリックラムダ
     13.6.2.1 ジェネリックラムダの内部構造
     13.6.2.2 std::variantとジェネリックラムダ
    13.6.3 クラステンプレートと継承の再帰構造
    13.6.4 constexpr if文
    13.6.5 意図しないname lookupの防止
     13.6.5.1 ジェネリックすぎるテンプレートを書かない
     13.6.5.2 ADLが本当に必要でない限り名前を修飾する
     13.6.5.3 ADL Firewallを使う
    13.6.6 Nstd::Type2Strの開発
    13.6.7 静的な文字列オブジェクト
     13.6.7.1 StaticStringのヘルパークラスの開発
     13.6.7.2 StaticStringの開発
     13.6.7.3 整数をStaticStringに変換する関数の開発
     13.6.7.4 ファイル位置を静的に保持したエクセプションクラスの開発
    13.6.8 関数型をテンプレートパラメータで使う
   13.7 注意点まとめ

  14 ダイナミックメモリアロケーション
   14.1 malloc/freeの問題点
   14.2 グローバルnew/deleteのオーバーロード
    14.2.1 固定長メモリプール
    14.2.2 グローバルnew/deleteのオーバーロードの実装
    14.2.3 プレースメントnew
    14.2.4 デバッグ用イテレータ
   14.3 クラスnew/deleteのオーバーロード
   14.4 STLコンテナのアロケーター
    14.4.1 STLコンテナ用アロケータ
    14.4.2 可変長メモリプール
    14.4.3 デバッグ用イテレータ
    14.4.4 エクセプション処理機構の変更

  15 デバッグ
   15.1 デバッガの使用
   15.2 gitの使用
   15.3 TATの短縮
    15.3.1 ビルド時間の短縮
    15.3.2 依存関係の整理
   15.4 自動単体テストの実施
   15.5 自動統合テストの実施
   15.6 事後的デバッグ
    15.6.1 ログの取得
    15.6.2 モニター
     15.6.2.1 メモリ保護機能
     15.6.2.2 スタック消費量の計測
   15.7 潜在的バグの削減
   15.8 難しいバグの対処
   15.9 助成の依頼
    15.9.1 現象1 - 不思議なハングアップ
    15.9.2 現象2 - グローバル変数の破壊
    15.9.3 現象3 - プロセスのスローダウン
    15.9.4 現象4 - バックトレースが見れない
    15.9.5 現象5 - newしたオブジェクトの破壊
    15.9.6 現象6 - STLのバグ?
    15.9.7 現象7 - 解放後のrvalueへのアクセス
   15.10 まとめ

  16 開発ツール
   16.1 コンパイラ
   16.2 デバッガ
    16.2.1 printfデバッグ
   16.3 エディタ/IDE
   16.4 筆者の開発ツール環境
    16.4.1 vim/neovimの設定
     16.4.1.1 設定ファイルと管理
     16.4.1.2 ドキュメント
     16.4.1.3 初期化
     16.4.1.4 独自スクリプト
      16.4.1.4.1 c/c++編集
      16.4.1.4.2 bash起動
      16.4.1.4.3 git連動
      16.4.1.4.4 ファイルタイプ設定
      16.4.1.4.5 その他
     16.4.1.5 外部パッケージ
   16.5 費用

  17 deps
   17.1 depsの構造
   17.2 depsの使い方
    17.2.1 ユースケース-循環依存を発見した場合、非0でexitする
    17.2.2 ユースケース-C++のソースコードを含むディレクトリを探す
    17.2.3 ユースケース-ディレクトリをパッケージとみなして、パッケージとソースコードの関係を示す
    17.2.4 ユースケース-パッケージ間の依存関係を示す
    17.2.5 ユースケース-パッケージ間の依存関係を構造的に表す
    17.2.6 ユースケース-パッケージ間の依存関係をplant umlで表す
    17.2.7 ユースケース-ソースコード間の依存関係をplant umlで表す
    17.2.8 ユースケース-パッケージでないディレクトリをそれとみなさない
   17.3 makeによる依存関係の維持

  18 用語解説
   18.1 型とインスタンス
    18.1.1 算術型
    18.1.2 汎整数型
    18.1.3 整数型
    18.1.4 算術変換
    18.1.5 汎整数拡張
    18.1.6 POD
    18.1.7 標準レイアウト型
    18.1.8 トリビアル型
    18.1.9 underlying type
    18.1.10 不完全型
    18.1.11 完全型
    18.1.12 ポリモーフィックなクラス
    18.1.13 インターフェースクラス
    18.1.14 constインスタンス
    18.1.15 constexprインスタンスと関数
    18.1.16 ユーザ定義リテラル演算子
    18.1.17 std::string型リテラル
   18.2 オブジェクトと生成
    18.2.1 特殊メンバ関数
    18.2.2 初期化子リストコンストラクタ
    18.2.3 継承コンストラクタ
    18.2.4 委譲コンストラクタ
    18.2.5 非explitなコンストラクタによる暗黙の型変換
    18.2.6 NSDMI
    18.2.7 一様初期化
    18.2.8 AAAスタイル
    18.2.9 オブジェクトの所有権
     18.2.9.1 オブジェクトの排他所有
     18.2.9.2 オブジェクトの共有所有
    18.2.10 オブジェクトのライフタイム
    18.2.11 クラスのレイアウト
   18.3 オブジェクトのコピー
    18.3.1 シャローコピー
    18.3.2 ディープコピー
    18.3.3 スライシング
   18.4 name lookupと名前空間
    18.4.1 ルックアップ
    18.4.2 name lookup
    18.4.3 two phase name lookup
    18.4.4 実引数依存探索
    18.4.5 ADL
    18.4.6 関連名前空間
    18.4.7 SFINAE
    18.4.8 name-hiding
    18.4.9 ドミナンス
     18.4.9.1 ダイヤモンド継承を含まない場合
     18.4.9.2 ダイヤモンド継承かつそれが仮想継承でない場合
     18.4.9.3 ダイヤモンド継承かつそれが仮想継承である場合
    18.4.10 ダイヤモンド継承
    18.4.11 仮想継承
    18.4.12 仮想基底
    18.4.13 using宣言
    18.4.14 usingディレクティブ
   18.5 expressionと値カテゴリ
    18.5.1 expression
    18.5.2 lvalue
    18.5.3 rvalue
     18.5.3.1 xvalue
     18.5.3.2 prvalue
    18.5.4 rvalue修飾
    18.5.5 lvalue修飾
    18.5.6 リファレンス修飾
    18.5.7 decltype
   18.6 リファレンス
    18.6.1 ユニバーサルリファレンス
    18.6.2 forwardingリファレンス
    18.6.3 perfect forwarding
    18.6.4 リファレンスcollapsing
    18.6.5 danglingリファレンス
    18.6.6 danglingポインタ
   18.7 エクセプション安全性の保証
    18.7.1 no-fail保証
    18.7.2 強い保証
    18.7.3 基本保証
   18.8 シンタックス、セマンティクス
    18.8.1 等価性のセマンティクス
    18.8.2 copyセマンティクス
    18.8.3 moveセマンティクス
   18.9 C++コンパイラ
    18.9.1 g++
    18.9.2 clang++
   18.10 C++その他
    18.10.1 オーバーライドとオーバーロードの違い
    18.10.2 実引数/仮引数
    18.10.3 範囲for文
    18.10.4 ラムダ式
    18.10.5 ジェネリックラムダ
    18.10.6 関数tryブロック
    18.10.7 単純代入
    18.10.8 ill-formed
    18.10.9 well-formed
    18.10.10 one-definition rule
    18.10.11 ODR
    18.10.12 RVO(Return Value Optimization)
    18.10.13 SSO(Small String Optimization)
    18.10.14 Most Vexing Parse
    18.10.15 RTTI
    18.10.16 Run-time Type Information
    18.10.17 simple-declaration
    18.10.18 typeid
    18.10.19 トライグラフ
    18.10.20 フリースタンディング環境
   18.11 ソフトウェア一般
    18.11.1 凝集度
    18.11.2 サイクロマティック複雑度
    18.11.3 Spurious Wakeup
    18.11.4 副作用
    18.11.5 is-a
    18.11.6 has-a
    18.11.7 is-implemented-in-terms-of
     18.11.7.1 public継承によるis-implemented-in-terms-of
     18.11.7.2 private継承によるis-implemented-in-terms-of
     18.11.7.3 コンポジションによる(has-a)is-implemented-in-terms-of
   18.12 非ソフトウェア用語
    18.12.1 割れ窓理論
    18.12.2 車輪の再発明

  19 演習
   19.1 プログラミング規約(型)
    19.1.1 演習-汎整数型の選択
    19.1.2 演習-汎整数型の演算
    19.1.3 演習-浮動小数点型
    19.1.4 演習-定数列挙
    19.1.5 演習-enum
    19.1.6 演習-配列の範囲for文
    19.1.7 演習-エイリアス
    19.1.8 演習-constの意味
    19.1.9 演習-const/constexpr
    19.1.10 演習-危険なconst_cast
    19.1.11 演習-リテラル
    19.1.12 演習-適切なautoの使い方
    19.1.13 演習-ポインタの初期化
    19.1.14 演習-vector初期化
    19.1.15 演習-インスタンスの初期化
   19.2 プログラミング規約(クラス)
    19.2.1 演習-凝集度の意味
    19.2.2 演習-凝集度の向上
    19.2.3 演習-メンバ変数の初期化方法の選択
    19.2.4 演習-メンバの型
    19.2.5 演習-メンバ変数の初期化
    19.2.6 演習-スライシング
    19.2.7 演習-オブジェクトの所有権
   19.3 プログラミング規約(関数)
    19.3.1 演習-非メンバ関数の宣言
    19.3.2 演習-メンバ関数の修飾
    19.3.3 演習-特殊メンバ関数の削除
    19.3.4 演習-委譲コンストラクタ
    19.3.5 演習-copyコンストラクタ
    19.3.6 演習-moveコンストラクタ
    19.3.7 演習-関数分割
    19.3.8 演習-オーバーライド関数の修飾
    19.3.9 演習-オーバーライド/オーバーロード
    19.3.10 演習-オーバーロードによる誤用防止
    19.3.11 演習-仮引数の修飾
    19.3.12 演習-constexpr関数
    19.3.13 演習-エクセプションの型
   19.4 プログラミング規約(構文)
    19.4.1 演習-コンテナの範囲for文
    19.4.2 演習-ラムダ式
    19.4.3 演習-ラムダ式のキャプチャ
   19.5 プログラミング規約(演算子)
    19.5.1 演習-三項演算子
    19.5.2 演習-delete
    19.5.3 演習-sizeof
    19.5.4 演習-dynamic_castの削除
    19.5.5 演習-キャスト
   19.6 プログラミング規約(スコープ)
    19.6.1 演習-usingディレクティブ
   19.7 プログラミング規約(その他)
    19.7.1 演習-アサーションの選択
    19.7.2 演習-assert/static_assert
   19.8 SOLID
    19.8.1 演習-SRP
    19.8.2 演習-OCP
    19.8.3 演習-LSP
    19.8.4 演習-ISP
    19.8.5 演習-DIP
    19.8.6 演習-SOLIDの定義
   19.9 デザインパターン
    19.9.1 演習-ガード節
    19.9.2 演習-BitmaskType
    19.9.3 演習-Pimpl
    19.9.4 演習-Accessorの副作用
    19.9.5 演習-Accessor
    19.9.6 演習-Copy-And-Swap
    19.9.7 演習-Immutable
    19.9.8 演習-Clone
    19.9.9 演習-NVI
    19.9.10 演習-RAIIの効果
    19.9.11 演習-RAII
    19.9.12 演習-Future
    19.9.13 演習-DI
    19.9.14 演習-Singleton
    19.9.15 演習-State
    19.9.16 演習-Null Object
    19.9.17 演習-Templateメソッド
    19.9.18 演習-Factory
    19.9.19 演習-Named Constructor
    19.9.20 演習-Proxy
    19.9.21 演習-Strategy
    19.9.22 演習-Visitor
    19.9.23 演習-CRTP
    19.9.24 演習-Observer
    19.9.25 演習-デザインパターン選択1
    19.9.26 演習-デザインパターン選択2
    19.9.27 演習-デザインパターン選択3
   19.10 開発プロセスとインフラ(全般)
    19.10.1 演習-プロセス分類
    19.10.2 演習-V字モデル
    19.10.3 演習-アジャイル
    19.10.4 演習-自動化
    19.10.5 演習-単体テスト
    19.10.6 演習-リファクタリングに付随する活動
    19.10.7 演習-リファクタリング対象コード
    19.10.8 演習-CI
   19.11 テンプレートメタプログラミング
    19.11.1 演習-パラメータパック
    19.11.2 演習-エイリアステンプレート
    19.11.3 演習-名前空間による修飾不要なoperator<<
    19.11.4 演習-std::arrayの継承
    19.11.5 演習-SFINAEを利用しない関数テンプレートの特殊化によるis_void
    19.11.6 演習-SFINAEを利用しないクラステンプレートの特殊化によるis_void
    19.11.7 演習-SFINAEを利用した関数テンプレートの特殊化によるis_void
    19.11.8 演習-SFINAEを利用したクラステンプレートの特殊化によるis_void
    19.11.9 演習-テンプレートテンプレートパラメータ
    19.11.10 演習-テンプレートパラメータを可変長にしたstd::is_same
    19.11.11 演習-メンバ関数の存在の診断
    19.11.12 演習-範囲for文のオペランドになれるかどうかの診断
    19.11.13 演習-配列の長さの取り出し
    19.11.14 演習-配列の次元の取り出し
    19.11.15 演習-関数型のテンプレートパラメータを持つクラステンプレート

  20 解答
   20.1 プログラミング規約(型)
    20.1.1 解答-汎整数型の選択
    20.1.2 解答例-汎整数型の演算
    20.1.3 解答例-浮動小数点型
    20.1.4 解答-定数列挙
    20.1.5 解答例-enum
    20.1.6 解答例-配列の範囲for文
    20.1.7 解答例-エイリアス
    20.1.8 解答-constの意味
    20.1.9 解答例-const/constexpr
    20.1.10 解答例-危険なconst_cast
    20.1.11 解答例-リテラル
    20.1.12 解答-適切なautoの使い方
    20.1.13 解答-ポインタの初期化
    20.1.14 解答-vector初期化
    20.1.15 解答例-インスタンスの初期化
   20.2 プログラミング規約(クラス)
    20.2.1 解答-凝集度の意味
    20.2.2 解答例-凝集度の向上
    20.2.3 解答-メンバ変数の初期化方法の選択
    20.2.4 解答-メンバの型
    20.2.5 解答例-メンバ変数の初期化
    20.2.6 解答例-スライシング
    20.2.7 解答例-オブジェクトの所有権
   20.3 プログラミング規約(関数)
    20.3.1 解答例-非メンバ関数の宣言
    20.3.2 解答例-メンバ関数の修飾
    20.3.3 解答例-特殊メンバ関数の削除
    20.3.4 解答例-委譲コンストラクタ
    20.3.5 解答例-copyコンストラクタ
    20.3.6 解答例-moveコンストラクタ
    20.3.7 解答例-関数分割
    20.3.8 解答-オーバーライド関数の修飾
    20.3.9 解答例-オーバーライド/オーバーロード
    20.3.10 解答例-オーバーロードによる誤用防止
    20.3.11 解答例-仮引数の修飾
    20.3.12 解答例-constexpr関数
    20.3.13 解答-エクセプションの型
   20.4 プログラミング規約(構文)
    20.4.1 解答例-コンテナの範囲for文
    20.4.2 解答例-ラムダ式
    20.4.3 解答例-ラムダ式のキャプチャ
   20.5 プログラミング規約(演算子)
    20.5.1 解答例-三項演算子
    20.5.2 解答例-delete
    20.5.3 解答例-sizeof
    20.5.4 解答例-dynamic_castの削除
    20.5.5 解答-キャスト
   20.6 プログラミング規約(スコープ)
    20.6.1 解答-usingディレクティブ
   20.7 プログラミング規約(その他)
    20.7.1 解答-アサーションの選択
    20.7.2 解答例-assert/static_assert
   20.8 SOLID
    20.8.1 解答例-SRP
    20.8.2 解答例-OCP
    20.8.3 解答例-LSP
    20.8.4 解答例-ISP
    20.8.5 解答例-DIP
    20.8.6 解答-SOLIDの定義
   20.9 デザインパターン
    20.9.1 解答例-ガード節
    20.9.2 解答例-BitmaskType
    20.9.3 解答例-Pimpl
    20.9.4 解答-Accessorの副作用
    20.9.5 解答例-Accessor
    20.9.6 解答例-Copy-And-Swap
    20.9.7 解答例-Immutable
    20.9.8 解答例-Clone
    20.9.9 解答例-NVI
    20.9.10 解答-RAIIの効果
    20.9.11 解答例-RAII
    20.9.12 解答例-Future
    20.9.13 解答例-DI
    20.9.14 解答例-Singleton
    20.9.15 解答例-State
    20.9.16 解答例-Null Object
    20.9.17 解答例-Templateメソッド
    20.9.18 解答例-Factory
    20.9.19 解答例-Named Constructor
    20.9.20 解答例-Proxy
    20.9.21 解答例-Strategy
    20.9.22 解答例-Visitor
    20.9.23 解答例-CRTP
    20.9.24 解答例-Observer
    20.9.25 解答-デザインパターン選択1
    20.9.26 解答-デザインパターン選択2
    20.9.27 解答-デザインパターン選択3
   20.10 開発プロセスとインフラ(全般)
    20.10.1 解答-プロセス分類
    20.10.2 解答-V字モデル
    20.10.3 解答-アジャイル
    20.10.4 解答-自動化
    20.10.5 解答-単体テスト
    20.10.6 解答-リファクタリングに付随する活動
    20.10.7 解答-リファクタリング対象コード
    20.10.8 解答-CI
   20.11 テンプレートメタプログラミング
    20.11.1 解答例-パラメータパック
    20.11.2 解答例-エイリアステンプレート
    20.11.3 解答例-名前空間による修飾不要なoperator<<
    20.11.4 解答例-std::arrayの継承
    20.11.5 解答例-SFINAEを利用しない関数テンプレートの特殊化によるis_void
    20.11.6 解答例-SFINAEを利用しないクラステンプレートの特殊化によるis_void
    20.11.7 解答例-SFINAEを利用した関数テンプレートの特殊化によるis_void
    20.11.8 解答例-SFINAEを利用したクラステンプレートの特殊化によるis_void
    20.11.9 解答例-テンプレートテンプレートパラメータ
    20.11.10 解答例-テンプレートパラメータを可変長にしたstd::is_same
    20.11.11 解答例-メンバ関数の存在の診断
    20.11.12 解答例-範囲for文のオペランドになれるかどうかの診断
    20.11.13 解答例-配列の長さの取り出し
    20.11.14 解答例-配列の次元の取り出し
    20.11.15 解答例-関数型のテンプレートパラメータを持つクラステンプレート

  21 参考文献
   21.1 プロセス・プラクティス
   21.2 設計・デザイン
   21.3 C++・C

  22 あとがき
   22.1 インフラ
   22.2 プロセス
   22.3 プログラマ(人材)
   22.4 まとめ

  23 Sample Code
   23.1 vim
   23.2 C++
   23.3 etc

1 イントロダクション

本ドキュメントは、 C++でのプログラミング、 デザイン、 ソフトウェア開発におけるプロセス、ワークフロー等に対する原理、原則をまとめたものである。

ソフトウェア工学を実践的に学習した者には明らかなように、 ソフトウェア工学はトレードオフを扱う学問である。 従って、後述する、しないにかかわらずソフトウェアの原理、原則は、 常にそれが正しいとは限らず、またそれらが互いに矛盾することもある。 老子の至言「道の道とすべきは、常の道に非ず」のごときものである。

ソフトウェア開発の現場においては、このことを常に念頭に置き、 慎重且つ深い洞察を以って、これらを実践すべきである。

1.1 本ドキュメントの目的

「守破離」とは、日本の伝統武道、技芸の修行者が歩むべき習熟モデルである。 「守」、「破」、「離」それぞれが以下のような修行者の習熟レベルと、それに基づいた行動規範を表す。

• 「守」- 未熟な修行者であり、まずは、先人の残した「形(型)」を無批判に受け入れ、それを反復すること
• 「破」-「形」に習熟した修行者であり、「形」に自らの工夫を加えながら、より高いレベルを探求すること
• 「離」- 最高レベルに到達した修行者であり、自らが「形」を作り出すこと

このドキュメントは、

• 「守」のレベルにあるC++プログラマに「形」を提供すること
• そのようなプログラマの「破」への道しるべとなること
• このドキュメントを批判的に読むことで、「破」のプログラマに「離」への切っ掛けを与えること
• C++で開発を行うチームが作り出すソースコードに規律や整合性を与えること、 もしくは守るべき規範のボトムラインを示すこと

を目的とする。

1.2 本ドキュメントの次に

本ドキュメントを読み、理解したプログラマの次のステップのために、 巻末に「参考文献」を設けた。

それらを読破し、合理的理由でこれらに倣い、もしくは批判できるようになることで、 「守」が終了し、「破」へと進むことができると考えられる。

1.3 改訂履歴

• V18.02
  • パッケージの公開ヘッダの格納ディレクトリをCMakeのガイドラインにあわせた
  • depsの構造、CMakeLists.txtの追加
  • アーキテクチャのファイル構造も上記に合わせた @ ファイル構造を表すツリー構造の表現をplant umlのstartsaltを使用するようにした
• V18.01
  • ファイル構造の刷新。内容のアップデートはない。
• V17.07
  • ソフトウェアプラクティスに加筆
• V17.06
  • 用語の統一、タイポの修正
  • usingディレクティブのルールを緩和
  • 特殊関数の宣言の説明のテーブルを修正
• V17.05
  • Strategyの使用例を追加
  • Factoryの使用例を追加
  • オブジェクトの所有権に「オブジェクトの排他所有」と「オブジェクトの共有所有」を追加
• V17.04
  • inline namespaceの使用を緩和
  • プリプロセッサ命令の使用を緩和
  • ラムダ式によるオブジェクトの初期化を追加
  • Pimpl/DIの使用例を追加
• V17.03
  • g++/clang++バージョンアップ
  • WSL -> WSL2
  • Ubuntu 18 -> Ubuntu 22
• V17.02
  • googletest-release-1.11.0 -> googletest-release-1.12.1
  • googletest-release-1.11.0/ -> googletest/
  • リポジトリ再構築
  • キーワードのリンク張り
• V17.01
  • visitorパターンのクラス図を詳細に表現
  • observerパターンのファイルの依存関係の修正
  • copy代入演算子、move代入演算子のルール追加
  • 仮想関数の宣言に使用するoverride、finalのルール変更
  • = deleteしたオーバーロードの例を強化
  • using宣言/usingディレクティブの制限強化
  • AAAスタイル(almost always auto)の説明の追加と採用
  • doxygenのコメントスタイルを変更
• V17.00
  • C++17に対応
    • ルールや解説追加
      • = {}を使用した初期化の型推論に対する規制追加
      • std::experimental::filesystem -> std::filesystem
      • 戻り値のルール追加
      • 畳みこみ式の解説
      • constexpr ifの解説
      • 自動変数のルール追加(if文とswitch文の条件式と初期化の分離)
      • constexprラムダ式に関するルール追加
      • [[fallthrough]]属性のルール追加
    • リファクタリング
      • クラステンプレートのテンプレート引数推論の使用
      • 構造化束縛の使用
      • std::pair<bool, T> -> std::optional
      • 関数の引数型std::string const& -> std::string or std::string_view
      • staticなメンバ変数初期化をクラス内部で行うため、inlineを使用
      • std::byteの使用
      • T::value -> T_v
      • T::type -> T_t
      • static_assert(COND, ““) -> static_assert(COND)
      • [[nodiscard]]属性の使用
  • エクセプションを発生させいない関数にnoexceptを付加
  • テンプレートの命名規則を追加し、それに合わせてテンプレート識別子変更
  • コードクローンの削除
  • 「一様初期化(uniform initialization)」の規制変更
• V08.XX
  • ファイル位置を静的に保持したエクセプションクラスの基底クラスを指定できるように変更
  • ダイナミックメモリアロケーションでメモリ不足等の通知用エクセプションオブジェクトを変更
  • リファクタリング
    • example/ref_async_rN
    • example/deps
    • exercise/solid_[aq]
    • exercise/programming_convention_[aq]
  • new T -> std::make_unique<T>()に変更
  • Immutableパターンのリンクの追加
  • cppcheckの使い方追加
  • noexceptのルールを追加
  • コンパイラのバージョンアップ
    • g++ 9.3 -> 10.3
    • clang++ 10.0 -> 12.0
  • 「デバッグ」に現象を追加
  • Pimplの例にコードを追加
  • ファイル属性の見直し
  • cygwinでもexampleがビルドできるようにした。
  • make formatの修正
  • pngファイル再生成
  • vim_configをアップデート
  • Nstd::Seq -> index_sequenceとし、utilityのものを使用するようにした。
  • 「enumによるビットマスク表現」をC++の正式名称である「BitmaskType」に変更
  • 「一様初期化(uniform initialization)」を積極的に使うように変更
  • 「多重継承」のルールを緩和
  • 「テンプレートメタプログラミング」に「静的な文字列オブジェクト」を追加
  • clang++のコードカバレッジ出力サポート
  • googletest-release-1.10.0 -> googletest-release-1.11.0
  • md_gem
    • 外部のリポジトリに移動
    • 新規機能に合わせた修正
    • md_genがない場合でも、exercise/build.shが使えるようにした。
  • 細かなバグ修正
• V07.XX
  • 「デザインパターン」に下記を追加
    • Cでのクラス表現
    • CRTP(curiously recurring template pattern)
  • 「アーキテクチャ」の章を追加
  • 「デバッグ」中にあった「deps」を単独の章に移動
  • 「開発プロセスとインフラ」のまとめの修正
  • exerciseの章立ての見直しとリンク追加
  • const T -> T const
  • 「用語解説」の追加
    • 「シンタックス、セマンティクス」に説明を追加
    • 「RTTI」に説明を追加
    • 「リファレンスcollapsing」を追加
    • 用語を階層化
  • ドキュメント生成
    • xxx/build.shの見直し
    • ソースコードのフォーマット用スクリプト追加
• V06.00
  • 「ダイナミックメモリアロケーション」の章を追加
• V05.XX
  • 章、節等の修正、追加
    • 「テンプレートメタプログラミング」章を追加
    • exerciseにテンプレートメタプログラミングの章を追加
    • 静的ポリモーフィズムよるTemplateメソッドの例を追加
• V04.XX
  • 「プログラミング規約」の変更、追加
    • 名前空間のルールを追加
    • 特殊メンバ関数のルール変更
  • 「デバッグ」章を追加
  • 「用語解説」の変更、追加
    • glvalueの説明追加
  • その他
    • example/配下のコードの整理・整頓
    • tools/export_exercise.shのバグフィックス
• V03.XX
  • 「プログラミング規約」の変更、追加
    • エクセプション処理ルールを追加
    • newに対するルールを追加
    • 名前空間のルールを追加
    • 「一様初期化」のルールを変更
  • 「用語解説」の変更、追加
    • RVO/SSO等の用語解説を追加
    • 「スライシング」の説明とルールの場所変更
  • 章、節等の修正、追加
    • 「開発ルール」、「vimの設定」の追加
    • exerciseにSOLIDの章を追加
  • サンプルコードの修正、追加
    • stringstream -> ostringstream
    • cygwinで動作しないUTをcygwin上ではDISABLEDに
    • spin lockの例を追加
  • その他
    • ./tools/export_exercise.shでエクスポートするファイルが足りていない問題の対処
    • gitコミット漏れの修正
• V02.XX
  • 章、節等の修正、追加
    • SOLIDを単体の章にして、デザインパターンの前に移動
    • exerciseの問題にタイトルを付加
    • exerciseのデザインパターン(実践)に演習追加
    • 「using宣言/usingディレクティブ」、 「実引数依存探索(ADL)」追加
    • 「How to make this document」にexerciseのコードの説明追加
    • 改訂履歴をイントロダクションに掲載
    • 「セマンティクス」、「オーバーライドとオーバーロードの違い」等の解説追加
    • rvalue、コンパイラ自動生成関数の定義等を「プログラミング規約」から移動
    • rvalue、スライシング、オブジェクトの所有権に図を追加して、説明を強化
  • サンプルコードの修正、追加
    • リリース用ツールのリファクタリング
    • 「並行処理」のプログラムのバグ修正
    • リリース前テスト用exercise/build.sh、sample/build.shを追加
  • ドキュメント生成
    • ./tools/build.shにpdf化で右端がカットされてしまう画像の検出機能追加
    • ./tools/git_ci_release.shでgit tagの付加
    • 参照->リファレンス、例外->エクセプション等の用語の使い方の見直し
• V01.XX
  • 章、節等の修正、追加
    • 「推定有罪」の追加
    • 「命名規則」の章立てを大幅に見直し
    • 「並行処理」を追加
    • 「struct」の規則の追加
    • 「汎整数型」を追加
    • 「コード解析」を追加
    • 「Named Constructor」を追加
    • 「凝集度」の説明を追加
    • 「 配列」を追加
    • 「開発プロセスとインフラのまとめ」を追加
    • 「演習」と「解答」を追加
  • サンプルコードの修正、追加
    • sanitizerやscan-buildでテストを容易に
    • 単体テストで使用するアサーションをEXPECT_XXXからASSERT_XXXに
    • 「オーバーライド」のサンプルコードを追加
    • 「constexpr関数」にサンプルコードを追加
  • ドキュメント生成
    • 各章の番号廃止
    • ドキュメント生成用のbuild.sh追加
    • shellスクリプト類を./tools/に移動
    • ドキュメント生成ツールをrubyからpython3に変更

1.4 本ドキュメントの修正・改善

本ドキュメントをソフトウェア開発のルールとして採用したチームのプログラマにとって、 本ドキュメントは守るべき「形」であるが、「形」であることは不変であることを意味しない。 むしろ、ソフトウェア工学の進歩やチームの習熟に合わせ、その時点で最も正しいであろうルール、 プラクティスを積極的に導入することで、「形」の陳腐化を防ぐべきである。 このことは、スコット・メイヤーズ氏によるEffective C++の第1版から第3版、 およびEffective Modern C++までの変遷を読むことで、より深い理解が得られるはずである。 従って、「破」や「離」のレベルにあるプログラマは、 このドキュメントや、このドキュメントから派生した(もしくは、それとは無関係な) チームのルールの内容を定期的に見直し、より高いレベルへと改善させるよう努めてほしい。

1.5 例示したコードの説明

次章以降では、ソースコードを使って説明を行う場合がある。このような場合の注意点を述べる。

• 「…」のみで構成された行は、ソースコードの省略を表す。
• 特定の規則、法則、慣習等を説明するためのソースコードは、シンプルさを優先するため、 その他の規則、法則、慣習に従っていない場合がある。特に識別子に関しては、 「命名規則」に従っていない場合が多い。 また、一般にSTLのコンテナクラスやstd::stringをnewする必要はないが、 コードの動作を示すためにあえてそのようにする場合がある。
• ソースコード内に動作説明のような本来不要なコメントがあるのは、 読者にその意味を知らせるためであるため、製品コードのコメントをこのようにするべきではない。
• 例示したコードの動作の確認、明示のために google test(gtest)のアサーション(下表)を使用する。

• 問題を示すために掲載したコードは、実行すると不具合を発生させることがある。 そういった場合、下記のように単体テストのラベルにDISABLED_を付けることで、 その実行を抑止することがある。

    TEST(DISABLED_Xxx, yyy)
    {
        // 単体テスト
    }

1.6 本ドキュメントでの言葉の使い方の注意

• 参照
  • 「～を参照する」というような文脈で使われる「参照」はそのまま使用する。
  • C++での参照型を表す参照は使わず、代わりに「リファレンス」を使用する。
• 例外
  • 「～の場合は例外である」というような文脈で使われる「例外」はそのまま使用する。
  • C++でthrowすると発生する事象を表す例外は使わず、代わりに「エクセプション」を使用する。
• classとクラス
  • classはC++のキーワードとして使用する。
  • クラスは上記以外で使用する。
• プログラミングとコーディング、ソースコードとコード、インスタンスとオブジェクト
  • 同じような意味で使用する。

2 ソフトウェアプラクティス

ピーター・ドラッカーは「プロフェッショナルの条件」の中で、

    紀元前440年頃、ギリシャ彫刻家フェイディアスはアテネのパンテオンの庇に建つ彫刻郡を完成させたが、
    フェイディアスの仕事の請求書に対して、アテネ会計官は「彫刻の背中は見えない。
    見えない部分まで彫って請求してくるとは何事か」と全額の支払いを拒んだ。フェイディアスは言った。
    「そんなことはない。人々が見えない彫刻の背中は、神々の目が見ている。」

ドラッカーはこの逸話を引用することで、 プロフェッショナルとは外部からの承認や評価を超えて、 自己の内なる基準に忠実であり、 目に見えない部分にも最高の品質を求める人物であるべきだと説明している。 つまり、プロフェッショナルは、自分の仕事に対する誠実さと完璧を追求することによって、 自己の専門性と倫理観を高める人物であるとドラッカーは示している。 この逸話は、プロフェッショナリズムの本質が単に技術的なスキルや知識にあるのではなく、 仕事に対する深い献身と責任感にあることを強調している。

ドラッカーの考えるプロフェッショナルに、 ソフトウェアエンジニアがそのレベルに到達するために重要であると考えられる原則・法則を下記に紹介する。

• プログラマの行動に関する原則・法則
  • DRYの原則
  • KISSの原則
  • ボーイスカウトの規則
  • YAGNIの原則
  • Name and Conquer
  • ノコギリの刃を研ぐ
  • 推定有罪
• デザイン、プログラミングに関する原則・法則
  • デメテルの法則
  • コンウェイの法則
  • Inside-Outの原則
  • SOLID

2.1 DRYの原則

DRYとは、“Don’t repeat yourself.”の略であることから推測できるように、 「ソフトウェア開発での繰り返し作業や成果物の重複を避けよ」という原則である。

2.1.1 作業の繰り返し

ソフトウェア開発におけるプログラマのワークフローは下記のようなものである。

ソフトウェア開発において、この流れの繰り返しは避けられないが、 この一連の作業のうち、少なくとも「ソースコードのビルドとデプロイ」と、 「新規ソースコード周辺の回帰テスト」での手作業のほとんどを自動化により回避可能である。

もし、これらにまつわる作業のほとんどが手動で行われていれば、 これらに多くの工数が奪われる。 また、手作業によるミスは避けられず、それによりさらに多くの工数が奪われる。

容易に推測できるように、これらの自動化は絶大な効果を発揮するため、 生産性改善の必須項目となっている(「自動単体テスト」、「自動統合テスト」参照)。

様々な自動化にスクリプト言語の習得が必要ならば、それを良い学習機会と捉えるべきである。 その投資対効果は間違いなく、ポジティブである。

2.1.2 成果物の重複

成果物の重複とは、

• コードクローン(ほぼ同じソースコードの断片)
• ソースコードに書いてあることをそのまま自然言語で説明したコメント
• ソースコードを読むことで容易にわかる詳細設計ドキュメント

等を指す。

成果物の重複の中で最も罪深いものはコードクローンである。コードクローンにより、

• ソースコード修正時にその箇所が多岐にわたるため、デグレードや修正漏れの原因になる。
• コードレビューの時間が延びる。
• ビルドが遅くなる。
• リポジトリが不要に大きくなる。

等の様々な問題が発生する。また、コードクローンは、コードクローンの原因にもなるため、 これらの問題は時とともに加速度的に大きくなる。

言語仕様に精通し、プログラミングイデオムや、デザインパターンを学び、 その知識を利用して定期的にリファクタリングを行うことでコードクローンの発生は軽減、回避可能である。

2.2 KISSの原則

“Keep it simple, stupid!”の頭文字からなる原則であり、意味は読んで字のごとしである。

「フェルマーの最終定理」で有名なフェルマーは友人にあてた手紙の冒頭で、 時間不足のため手紙が長くなることを謝った。 手紙の推敲不足ならば謝罪で十分だろうが、対象が設計ドキュメントや、ソースコードの場合、 謝罪では問題は解決しない。 なぜなら、そのドキュメントやソースコードは次の開発のベースラインとなるからである。

不要な複雑さを持ったそれらは、明日行うかもしれない次の開発を、間違いなく難しくさせる。 この設計上の負債が一定量を上回れば、それ自体が不要な複雑さを増やす原因となり、 問題はさらに複雑になる。

残念ながら、一旦この負のスパイラルに陥ってしまえば、これを止め、逆転させることは極めて困難であり、 スクラッチから作り直すよりも、多くの工数、スキルを要する。

設計ドキュメントや、ソースコードから不要な複雑さを切り捨て、シンプルに保とう。 時間的制約で、すぐにそれに取り掛かれない場合は、成果物にマーキングを行い、 やるべきことを忘れないようにしよう(マーキングキーワードにはTBR(== to be refactored)を推奨)。 時間ができた時には、そのキーワードを検索し、すぐに整理・整頓、リファクタリングに取り掛かろう。 中国のことわざに「双葉のうちに刈らずんば、斧をもちうる」とある。 斧が必要になる前に、必ずその問題を刈り取ろう。

2.3 ボーイスカウトの規則

ボーイスカウトの規則の元々の意味は、 「山に行ったときよりも、山から帰るときの方がきれいになるように行動せよ」 というものである。転じて、 「チェックアウトされたソースコードよりも、 コミットされるソースコードの方がきれいになるようにプログラミングせよ」 という意味のソフトウェア開発における規則となった。

この規則を守るために、まずはリポジトリへのコミット前に変更差分の自己レビューを行い、 以下のような不要なコードが残っていないかチェックしよう。

• 不要なコメント
• 改行コードの違い
• タイポ
• 不要なスペース文字
• printfデバッグの残骸
• 一時的な#if 0/#if 1

この規則には、もう一点重要な示唆が含まれている。 グローバル変数の多さや、関数の大きさを指摘された時に、「最初から、汚くて．．．」 というような言い訳をするプログラマは珍しくない。それはおそらく真実であろうが、 それでも、もともと汚かったソースコードをさらに汚してしまったのでは、 問題は大きくなるばかりである。 従って、この規則には「グローバル変数やそれらへのアクセス箇所を増やさない」、 「関数をこれ以上大きくしない」程度の努力は常にするべきである、ということも含まれている。

2.4 YAGNIの原則

YAGNI(You ain’t gonna need it)とは、「機能(要件)は実際に必要となるまで実装しない」 という原則である。これは、

• 単なる思い付きや予想により、先回りして実装したコードの多くが不要である。
• その時点で必要でない機能は、それが存在するだけで工数を浪費する。
  • ビルド時間や単体テスト時間が余計にかかる。
  • 必要な機能追加に、余計な負担を与える(コードが不要に複雑になる)。
• 本来やるべきことに集中した方が良い結果が得られる。

といったエクストリームプログラミングのエクスパートたちの主張である。 なお、上記の「単なる思い付きや予想」とは、演繹的推論とは異なる。 演繹的推論により、

• 近い将来その機能が必要になる。
• その機能の実装を必要になるまで先送りするよりも、 今行った方が良い合理的な理由がある(記憶がホットである等)。

というような場合は、この原則の限りではない。

「コンウェイの法則」でも述べるように、 「レイヤに水平分割されたパッケージ構造を持つソフトウェア」を、 「各チームや個人がそれぞれのパッケージ開発に責任を持つ組織」が開発を行う場合、 レイヤ毎に開発が進められ、各パッケージの結合は後回しにされる。 そのため、各パッケージの開発者は実際に必要になるかどうか確定しないものを開発することになる。 このスタイルは明らかにYAGNIの原則に違反する。 これが、「各チームや個人がそれぞれのパッケージの開発に責務を持つ組織」 が非効率になってしまう理由の一つである。

2.5 Name and Conquer

かつてデカルトは、「困難を分割せよ」といった。 そのままでは複雑すぎて理解不可能な対象物を、分割して理解していく方法は、 現在では「要素還元」や「divide-and-conquer(分割統治)」と呼ばれる。 このdivide-and-conquerは、デカルト以前から、現在に至るまで、そして今後も、 対象物を理解するための極めて有効な手段である。

これと同等に強力な手法がname-and-conquer(命名統治)である。 対象物が適切に命名されてなければ、我々はそれを正確に記憶することが難しい。 正確に記憶できなければ正確に理解できない。 仮に理解できたとしても他者とその理解を共有することは難しい。 一方、それに適切な名前を付けることで、その対象物の理解が始まり、他者との理解の共有が可能となる。 「クラウド・コンピューティング」という命名がその好例である。

以下のような事に気を付け、自分たちが使う概念やソフトウェア構成物に、適切な命名をしよう。

• その名前が持つ意味の揺らぎをプロジェクトから排除する。
• すでにグローバルスタンダードとして存在する名前を別の用途で使わない。
• 自分たちが必要とする概念が、すでにグローバルスタンダードな名前を持つのであれば、 それをそのまま使用する。
• 新規概念を理解できていないか、それ自体が大きすぎれば、それへの命名は難しい。 その場合、その概念を分割し、分割された部分に命名する。
• 命名に誤りはつきものである。一旦定めた名前よりも適切なものが見つかった場合、 その修正を躊躇してはならない。
• XXXコントローラや、XXXマネージャ等の命名は、それらの責務が限定されない場合が多い (こういった名前を、「強すぎる名前」と呼ぶ)。もっと限定的な(弱い)名前を付ける。

「命名規則」に詳細をまとめたので参照してほしい。

2.6 ノコギリの刃を研ぐ

まずは、「7つの習慣」 からの引用を紹介する。

    森の中で木を倒そうと、一生懸命ノコギリを挽いている樵(きこり)に出会ったとしよう。
      「何をしているんですか」
    とあなたは訊く。すると
    「見れば分かるだろう」
    と、無愛想な返事が返ってくる。
      「この木を倒そうとしているんだ」
      「すごく疲れているようですが．．．。いつからやっているんですか」
    あなたは大声で尋ねる。
      「かれこれもう五時間だ。くたくたさ。大変な作業だよ」
      「それじゃ、少し休んで、ついでにそのノコギリの刃を研いだらどうですか。
        そうすれば仕事がもっと早く片付くと思いますけど」
    あなたはアドバイスをする。
      「刃を研いでいる暇なんてないさ。切るだけで精一杯だ」
    と強く言い返す。

残念ながら、ソフトウェア開発現場でも、この滑稽な状況を頻繁に目にする。 このようになりたくなければ、定期的にノコギリの刃を研ぐことである。 そのヒントを下記する。この他にもたくさんあるはずである。

• タッチタイピングや開発ツールのショートカットを身に着ける。
• すぐれたエディタやIDEを使いこなす。
• printfデバッグのみに頼ることはやめて、すぐれたデバッガ(「デバッガの使用」参照)を使う。
• 「DRYの原則」を実践し、繰り返しの手作業をなくすためのツールを導入、開発する。
• 静的・動的解析ツールを利用し、最小の努力でバグやバグの元になる質の悪いコードを見つけ改善する。
• オープンソースを利用する。
• 新しい言語や、使い慣れた言語の最新機能を学ぶ。
• 効率的なプロセスを理解し、導入する。
• 定期的に書籍やウェブから最新技術情報を入手する。

こういったことに何一つ取り掛からないのであれば、「時間がない」とつぶやきながら、 切れないノコギリを挽き続けることになる。

2.7 推定有罪

言うまでもなく、推定無罪とは「何人も、有罪を宣告されない限り無罪である」という原則であり、 この順守は近代国家であるための必要条件となっている。 これは人権を守るといった観点のみでなく、 「悪魔の証明」 という言葉で表されるような「多くの場合、無罪の証明は技術的に困難である」 といった観点でも重要な原則である。 我々がそういった原則を順守している国家に属していることは大変結構なことではあるが、 この原則はソフトウェア開発においては当てはまらない。 にもかかわらず、これをソフトウェア開発に持ち込むプログラマがいる。

そういったプログラマの行動パターンは以下のようなものである。

• プログラミングルールを守らない。
• ソフトウェア工学的に良くないことだと知りつつ、下記のようなことを行う (おそらく、下記が良くないことであると知らないプログラマはいないだろう)。
  • グローバル変数を作る。
  • 巨大なソフトウェア構成物(ファイル、クラス、関数等)を作る。
  • コピー&ペースト・プログラミングをする(コードクローンを作る)。
  • コンパイラや静的解析ツールの警告を無視する。
• ソースコードのコミットに際して、プログラマが当然すべき以下のような作業をしない。
  • コミット予定のソースコードの自己レビューをする。
  • コミット予定のソースコード周辺の回帰テストをする。
  • コミット後、それを別のリポジトリにチェックアウトする等して、 コミットに抜け漏れが無いかを確認する。
  • コミット後のデグレード発生に対して、リポジトリ先頭の品質を回復させる。
• 会議等の時間を守らない。
• 自分のスキルの低さを気にしない。

等々挙げればきりがない。 これらの行動は、どの一つをとっても、組織やその組織の成果物を直ちに棄損したと証明することは難しいため、 推定無罪の原則を適用すれば、このプログラマの行動は無罪である。

良識あるプログラマから見れば、明らかに有罪である行動が無罪になる理由は、 その論拠となる原則が間違っているからである。 ソフトウェア開発の現場においては、常に推定有罪「無罪を証明しない限り有罪」の原則が正しい。 とは言え、先に書いたようにそれは「悪魔の証明」をすることになり、実践的には不可能である。

故にソフトウェア開発の現場における推定有罪の原則とは、 「無罪であると演繹推論できるものは無罪という前提の元、無罪を証明しない限り有罪である」 というようなものである。

この観点に従って、上記推定無罪プログラマの行動パターンを矯正すると下記のようになるだろう。

• プログラミングルールを守る。
• ソフトウェア工学的に良くないことはしない。
• ソースコードのコミットに際して、最低でも下記のような作業を行う。
  • コミット予定のソースコードの自己レビューをする。
  • コミット予定のソースコード周辺の回帰テストをする。
  • コミット後、それを別のリポジトリにチェックアウトする等して、 コミットに抜け漏れが無いかを確認する。
  • コミット後のデグレード発生に対して、リポジトリ先頭の品質を回復させる。
• 会議等の時間は守るか、守れない場合は前もって、その旨を開催者に伝える。
• 自分のスキルに気を配り、常に向上に努める。

当たり前のことであるが、意外なほど多くのプログラマが出来ていない。

2.8 デメテルの法則

最小知識の原則(Principle of Least Knowledge)とも呼ばれ、

• オブジェクトは、それ以外の構造やプロパティに対して(他のオブジェクトに対して)持っている知識、 前提を最小限にすべきである。

という設計上の制約である。

クラスAから生成されたオブジェクトaが、クラスBから生成されたオブジェクトbのメンバ関数 「void* B::f()」を呼び出し、戻りのポインタを何らかの型にキャストして使用するようなコードは、 この法則違反となる。 当然ながら、型付けの厳格なC++の仕様の裏をかくこのような記述は避けなければならない。

オブジェクトaが、オブジェクトbのメンバ関数「C& B::f()」を呼び出すことにより、 クラスCから生成されたオブジェクトcにアクセスし、 そのメンバ関数「C::g()」を呼び出す「a.f().g()」のような多重の呼び出しもこの法則違反となるが、 この例でのクラスCがstd::string constのように状態が不変で安定した仕様を持つならば、 このような多重呼び出しが問題になることは稀である。 一方で、この法則に従うと、クラスBにC::g()のラッパー関数を作ることになるため、 これをプロジェクト全体で守れば、多量のラッパー関数を作らざるを得なくなる。 その結果として、多くのクラスの凝集性(「凝集度」参照)が低下する。

これらを総合して考えると、 上記オブジェクトcが「ミュータブルである」、 もしくは「仕様が流動的である」ときのみにこの法則を適用するべきである。

2.9 コンウェイの法則

コンウェイの法則とは、 「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」 現象を説明するものである。

ソフトウェア開発を行う組織は、ドメイン知識に基づいた組織構造 (GUIチーム、ミドルウエアチーム、ドライバチーム等）を持つことが多い。 こういった組織が、コンウェイの法則に陥ってしまうと、

• ソフトウェア全体を、水平にパッケージ分割したアーキテクチャを構築する
• ドメイン組織に基づいたチームは、このパッケージの開発責任を持つ

ことになる。これは合理的な組織統治に思えるが、以下のような避けがたい問題を生み出す。

• パッケージのインターフェースや責務の修正には、組織間での調整会議が必要となる。 この会議には、多くの意思決定者が参加することになるが、 この会議参加者のインセンティブはさまざまであるため (自分のチームの責任範囲を小さくしたいという意図も働く)、 この会議での意思決定が技術的最適解になることは稀である。
• 大規模なソフトウェア開発では、パッケージのこのような修正は不可避であり、 そのたびに上記会議を招集することになる。参加者全員が理解できる言語は自然言語のみであるため、 この会議の趣旨を説明するためのパワーポイント資料を作ることになる。 このパワーポイント資料を作ることができる人員は、通常、優秀なプログラマであるため、 ただでさえ不足しがちな優良なヒューマンリソースをさらに不足させてしまう (この状態が定常化しパワポ資料ばかりを作っている、 かつて優秀だった元プログラマをパワーポッターと呼ぶ）。

また、このような組織構造は、各チームを担当パッケージの開発に集中させてしまうため、 ソフトウェア全体の開発責務(要件開発責務)の所在があいまいになる。 これにより、以下のような問題も生み出す。

• ソフトウェア全体として統一的に必要な要件(ログ、独自のアサート機能、共通ライブラリ) がおざなりにされ、パッケージごとにそのためのライブラリが作られるか、 そのようなものは一切作られないことになる。 何れにしても全体として統一感のないソースコードが出来上がる。
• 「YAGNIの原則」に違反するため、要件の実装とは無関係なコードが作られる。
• 下位パッケージに依存する上位パッケージは、下位パッケージの進捗に強い影響を受け、 上位パッケージほど進捗が遅れる。
• 全パッケージが完成するまでソフトウェア全体のテストができないため、 ソフトウェア全体の進捗率を正しく計測することができない。

かくして、このような組織は、

• 長いミーティングが多く、そこでの意思決定は技術的最適解には程遠い。
• かつて優秀だったプログラマは、今ではパワーポイント資料作りを主な業務とするパワーポッター。
• 進捗率が、人の意思によってきめられており、進捗遅れが頻発する。
• 統一感がなく、不要に複雑で、クローンだらけのソースコードを作る。

これを防ぐためには、「ドメイン知識に基づいた組織構造をそのままソフトウェア開発に持ち込む」 ことをやめなければならない。

2.10 Inside-Outの原則

「Inside-Outの原則」というキーワードは「7つの習慣」でも使用されている。 この名著のそれは、 「何らかの問題が起こったときに、それを他責にすることなく(環境や他人の問題)、 まずは自分の管理可能なこと(自分の性格、物事の捉え方、感じ方、動機)に目を向けて対処する」 ことを求める。これは、これで重要な行動規範であるが、 ここで説明する「Inside-Outの原則」はこれとは異なる (もしかすると、「7つの習慣」からの引用かもしれないが）。

この原則は、GUIアプリケーションを「MVC」系のアーキテクチャで開発する場合 (それ以外の方法があるとは思えないが)、 「開発はGUI(View)からではなく、Modelから始めよ」という開発手順への制約である。

ViewはModelの画面への表出であり、Viewを表すためにModelがあるわけではない。 まずはModelの関係性を見極めることは、すぐれたGUIアプリケーション開発の要諦である。

ところが、多くのプログラマはGUIから作りたがる。これがModelに悪影響を与え (もしくは、Viewの中にModelを作りこみ、ViewとModelが癒着した構造を作る)、 容易にデグレードを引き起こす不安定なソフトウェアを作り出す。 このような悪構造は、 「DRYの原則」で述べたような「回帰テストの自動化」もほとんど不可能にさせる。

Modelから開発を始め、それを外部の「回帰テスト用ソフトウェア」から実行できるようにしよう。 その後、それをViewと組み合わせて実行できるようにすれば、 MVCに基づいたアーキテクチャと、 それを自動テストできるソフトウェアを入手できる。

2.11 SOLID

SOLIDとは下記に示す5つの原則である。

• 単一責任の原則(SRP)
• オープン・クローズドの原則(OCP)
• リスコフの置換原則(LSP)
• インターフェース分離の原則(ISP)
• 依存関係逆転の原則(DIP)

この5原則はオブジェクト指向(OOD/OOP)プログラミングにおいて特に重要なものであり、 すべてのプログラマはこれらに従って開発することが求められる。

これらの解説は、「プログラミング規約」の説明を行った後、 「デザインパターン」の直前で行う。

3 プログラミング規約

組織に秩序を与える法、道徳、慣習等をここではルールと呼ぶことにする。 当然ながら、秩序ある組織には良いルールがあり、混沌とした組織には悪いルールがあるか、 ルールはあっても守られていないか、そもそもルールが存在しない。

秩序あるソースコードとは、

• 可読性が高い。
  • 簡潔に記述されている。
  • 記述スタイルが統一されている(「コーディングスタイル」参照)。
  • ファイルや識別子の名前に規則性があり、適切に命名されている (「Name and Conquer」、「命名規則」参照)。
  • コメントの記法が統一されており、内容が適切である(「コメント」参照)。
• 保守、テスト、移植等が容易である。
• 型安全性が配慮されている。
• コンパイル警告レベルが高く、かつ指摘がない(「g++の警告機能」参照)。

のような特性を満たすものであるが、そうあるためには秩序ある組織と同様に良いルールが必要である。 本章の目的は、C++プログラミングにおけるそのようなルール(=プログラミング規約)を示すことである。

なお、型安全性とは、「正しく型付けされたソースコードは未定義動作をしない」 ことが保証されるという言語の特性である。 配列のオーバランが未定義動作を引き起こすことを考えれば明らかである通り、 C++は型安全性を保証しない。このことは、C++の劣等性を意味しないが、 それに配慮したプログラミング(型システムの最大限の利用等)が必要となることは事実である。

3.1 型とインスタンス

3.1.1 算術型

3.1.1.1 整数型

• 整数型には、整数の基本型(intやlong等)を直接使わずに、 cstdint で定義されている型エイリアスを使用する。
  • STLやPOSIX等の標準クラスや関数のインターフェースが基本型を直接使用している場合は、 その型に合わせるために基本型を直接使用する。
• 整数型には、特に理由がない限りに、int32_tを使用する。
• 整数型の変数が負にならないのであれば、uint32_tを使用する。
  • 符号あり型との演算がある場合は、その変数が負にならなくともint32_tを使用する。
  • 符号あり型と符号なし型との比較をしない。
• sizeofの値や配列の長さの保持等には、size_tを使用する。
• int32_tからint16_tや、int32_tからuint32_t等の値が変わる可能性がある代入を避ける。 やむを得ずそのような代入をする場合、下記のようなnarrow_castを使いこのような問題を緩和する。

    // @@@ example/programming_convention/type_ut.cpp 9

    template <typename DST, typename SRC>
    DST narrow_cast(SRC v)
    {
        static_assert(std::is_integral_v<DST> && std::is_integral_v<DST>,
                      "DST, SRC shoud be integral-type.");
        auto r = static_cast<DST>(v);

        assert((r < 0) == (v < 0));        // 符号が変わっていないことの確認
        assert(static_cast<SRC>(r) == v);  // bit落ちしていないことの確認

        return r;
    }

    // @@@ example/programming_convention/type_ut.cpp 28

    auto ui32 = narrow_cast<uint32_t>(128);                // 安全なint32_t -> uint32_t
    ASSERT_EQ(ui32, 128);                                  //
    ASSERT_DEATH(ui32 = narrow_cast<uint32_t>(-128), "");  // 危険なint32_t -> uint32_t

    auto i8 = narrow_cast<int8_t>(127);                    // 安全なint32_t -> int8_t
    ASSERT_EQ(i8, 127);                                    //
    ASSERT_DEATH(i8 = narrow_cast<int8_t>(128), "");       // 危険なint32_t -> int8_t

    i8 = narrow_cast<int8_t>(-1);                          // 安全なint32_t -> int8_t
    ASSERT_EQ(i8, -1);                                     //
    ASSERT_DEATH(i8 = narrow_cast<int8_t>(-129), "");      // 危険なint32_t -> int8_t

• 演習-汎整数型の選択

3.1.1.2 char型

• charはascii文字の保持のみに使用する。
• char*をvoid*の代わりに使わない。
• charがsingedかunsignedかは処理系に依存するため、char型を汎整数型として扱わない。 8ビット整数には、int8_tまたは、uint8_tを使用する。
  • バイトストリームを表現する場合、int8_t*、int8_t[]、uint8_t*、uint8_t[]のいずれかを使う。
• 演習-汎整数型の演算

3.1.1.3 std::byte型

• intよりもビット幅の小さい組み込み型の演算の結果は汎整数拡張によりint型になるため、 uint8_tのビット演算の型もintとなる。 intへの拡張が意図したものかどうかの判別は困難であるため、 uint8_tインスタンスにビット演算が必要な場合、 uint8_tの代わりに下記のようにstd::byte(「BitmaskType」参照)を用いる。

    // @@@ example/programming_convention/type_ut.cpp 50
    // uint8_tのビット演算例

    auto u    = uint8_t{0b1000'0001};
    auto ret0 = u << 1;
    // uint8_t ret1{u << 1};  // 縮小型変換のため、コンパイルエラー
    uint8_t ret1 = u << 1;

    static_assert(std::is_same_v<decltype(ret0), int>);  // u << 1はintになる
    ASSERT_EQ(0b1'0000'0010, ret0);
    ASSERT_EQ(0b0000'0010, ret1);

    // @@@ example/programming_convention/type_ut.cpp 64
    // uint8_tに代わりstd::byteを使用したビット演算例

    auto b    = std::byte{0b1000'0001};
    auto ret0 = b << 1;
    auto ret1 = std::byte{b << 1};

    static_assert(std::is_same_v<decltype(ret0), std::byte>);  // b << 1はstd::byteになる
    ASSERT_EQ(std::byte{0b0000'0010}, ret0);
    ASSERT_EQ(std::byte{0b0000'0010}, ret1);

• std::byteの初期化には{}を用いる(static_castを使用しない)。

    // @@@ example/programming_convention/type_ut.cpp 77

    std::byte b0{0b1000'0001};                           // OK
    auto      b1 = std::byte{0b1000'0001};               // OK
    std::byte b2 = static_cast<std::byte>(0b1000'0001);  // NG
    // std::byte b3 = 0b1000'0001;                       // NG コンパイルエラー

3.1.1.4 bool型

• bool型は、bool型リテラル(true/false)やbool型オブジェクトの保持のみに使用する。
• bool型を汎整数型として扱わない。bool型に++を使用しない(–はコンパイルできない)。

    // @@@ example/programming_convention/type_ut.cpp 95

    #if __cplusplus < 201703L  // 以下のコードはC++14以前ではコンパイルできるが、
                               // C++17以降ではコンパイルエラー

        auto b = false;

        ASSERT_EQ(1, ++b);  // NG 予想通り動作するが、boolの目的外使用
        ASSERT_EQ(1, ++b);  // NG bは2ではなく1
        // ASSERT_EQ(1, --b);  // NG コンパイルエラー
    #endif

• ポインタ型やboolを除く汎整数型のインスタンスをbool値として使用しない。

    // @@@ example/programming_convention/type_ut.cpp 111

    void g(int32_t* ptr0, int32_t* ptr1) noexcept
    {
        if (ptr0) {  // NG ポインタ型をbool値として使用
            return;
        }

        if (ptr1 == nullptr) {  // OK
            return;
        }

        ...
    }

3.1.1.5 浮動小数点型

• floatやdoubleのダイナミックレンジが必要な場合のみに、これらの型を使用する。 ちなみに銀河系の直径は1e+21メートル程度、プランク長は1.616229e-35メートルであるため、 銀河から素粒子までのサイズを一つの基本型で表す場合においても、 floatのダイナミックレンジに収まる。 従って、floatやdoubleが必要になる場合は極めて限られる。

• 演算順序等により誤差が生じることがあるため、floatやdoubleのインスタンスを、 ==、!=、>、<等で比較しない。

    // @@@ example/programming_convention/float_ut.cpp 11

    // 下記の0.01は2進数では循環小数となるため、実数の0.01とは異なる。
    constexpr auto a = 0.01F;  // 0.0000001010001111...
    constexpr auto b = 0.04F;  // 0.0000101000111101...

    //  ASSERT_EQ(0.05F, a + b);  // NG  a + b == 0.05Fは一般には成立しない。
    ASSERT_NE(0.05F, a + b);

    // @@@ example/programming_convention/float_ut.cpp 22

    /// @fn bool is_equal_f(float lhs, float rhs) noexcept
    /// @brief float比較用関数
    bool is_equal_f(float lhs, float rhs) noexcept
    {
        return std::abs(lhs - rhs) <= std::numeric_limits<float>::epsilon();
    }

    // @@@ example/programming_convention/float_ut.cpp 34

    // 下記の0.01は2進数では循環小数となるため、実数の0.01とは異なる。
    constexpr auto a = 0.01F;  // 0.0000001010001111...
    constexpr auto b = 0.04F;  // 0.0000101000111101...

    // floatの比較はis_equal_fのような関数を使う。
    ASSERT_TRUE(is_equal_f(0.05F, a + b));  // OK

• 一つの式にfloatとdoubleを混在させない。

    // @@@ example/programming_convention/float_ut.cpp 46

    // 上記例と似たソースコードであるが、下記のような問題が起こる
    /// @fn bool is_equal_d(double lhs, double rhs) noexcept
    /// @brief double比較用関数
    bool is_equal_d(double lhs, double rhs) noexcept
    {
        return std::abs(lhs - rhs) <= std::numeric_limits<double>::epsilon();
    }

    // @@@ example/programming_convention/float_ut.cpp 59

    // 下記の0.01は2進数では循環小数となるため、実数の0.01とは異なる。
    constexpr auto a = 0.01F;  // 0.0000001010001111...
    constexpr auto b = 0.04F;  // 0.0000101000111101...

    // a + bはfloatの精度のまま、is_equal_dの引数の型であるdoubleに昇格される。
    // 一方、0.05はdoubleであるため(循環小数をdoubleの精度で切り捨てた値であるため)、
    // a + b(floatの精度の値)と0.05の差はdoubleのepsilonを超える。
    //  ASSERT_TRUE(is_equal_d(0.05, a + b));  // NG
    ASSERT_FALSE(is_equal_d(0.05, a + b));

    // @@@ example/programming_convention/float_ut.cpp 73

    // is_equal_dを改良して、引数の型が統一されていない呼び出しをコンパイルエラーにできるようにした。
    /// @fn bool is_equal(FLOAT_0 lhs, FLOAT_1 rhs) noexcept
    /// @brief 浮動小数点比較用関数
    template <typename FLOAT_0, typename FLOAT_1>
    bool is_equal(FLOAT_0 lhs, FLOAT_1 rhs) noexcept
    {
        static_assert(std::is_floating_point_v<FLOAT_0>, "FLOAT_0 shoud be float or double.");
        static_assert(std::is_same_v<FLOAT_0, FLOAT_1>, "FLOAT_0 and FLOAT_1 shoud be a same type.");

        return std::abs(lhs - rhs) <= std::numeric_limits<FLOAT_0>::epsilon();
    }

    // @@@ example/programming_convention/float_ut.cpp 90

    // 下記の0.01は2進数では循環小数となるため、実数の0.01とは異なる。
    constexpr auto a = 0.01F;  // 0.0000001010001111...
    constexpr auto b = 0.04F;  // 0.0000101000111101...

    // a + bはfloatであり、0.05はdoubleであるため、下記コードはコンパイルできない。
    // ASSERT_TRUE(is_equal(0.05, a + b));
    ASSERT_TRUE(is_equal(0.05F, a + b));  // OK リテラルに型を指定して、引数の型を統一

• INFや、NANを演算で使用しない。
• 汎整数型の演算とは違い、0除算等の浮動小数点演算のエラーは、 通常、プログラム終了シグナルを発生させないため、 浮動小数点演算のエラーを捕捉する必要がある場合(ほとんどの場合、そうなる)は、 std::fetestexcept()、std::isnan()、std::isinf()等を使用してエラーを捕捉する。

    // @@@ example/programming_convention/float_ut.cpp 102

    int   global_zero{0};
    float div(float a, float b) noexcept { return a / b; }

    // @@@ example/programming_convention/float_ut.cpp 110

    std::feclearexcept(FE_ALL_EXCEPT);  // エラーをクリア

    div(1.0F, 0.0F);  // 関数の中で0除算するが、終了シグナルは発生しない
    ASSERT_TRUE(std::fetestexcept(FE_ALL_EXCEPT) & FE_DIVBYZERO);  // 0除算

    std::feclearexcept(FE_ALL_EXCEPT);  // エラーをクリア

    div(std::numeric_limits<double>::max(), 1);

    auto const excepts = std::fetestexcept(FE_ALL_EXCEPT);

    ASSERT_FALSE(excepts & FE_DIVBYZERO);  // 0除算
    ASSERT_TRUE(excepts & FE_INEXACT);     // 演算が不正確
    ASSERT_FALSE(excepts & FE_INVALID);    // 不正な操作
    ASSERT_TRUE(excepts & FE_OVERFLOW);    // 演算がオーバーフローを起こした
    ASSERT_FALSE(excepts & FE_UNDERFLOW);  // 演算がアンダーフローを起こした

    std::feclearexcept(FE_ALL_EXCEPT);  // エラーをクリア

    auto const a = 1.0F / global_zero;  // global_zero == 0
    ASSERT_TRUE(std::isinf(a));

    auto const b = std::sqrt(-1);
    auto const c = std::sqrt(-1);
    ASSERT_TRUE(std::isnan(b));
    ASSERT_FALSE(b == c);  // NaN == NaNは常にfalse

• できる限り浮動小数点の代わりに固定小数点を使用する (全ソースコードは「“example/programming_convention/fixed_point.h”」に掲載)。

    // @@@ example/programming_convention/fixed_point.h 6

    /// @class FixedPoint
    /// @brief BASIC_TYPEで指定する基本型のビット長を持つ固定小数点を扱うためのクラス
    /// @tparam BASIC_TYPE       全体のビット長や、符号を指定するための整数型
    /// @tparam FRACTION_BIT_NUM 小数点保持のためのビット長
    template <typename BASIC_TYPE, uint32_t FRACTION_BIT_NUM>
    class FixedPoint {
    public:
        FixedPoint(BASIC_TYPE                                integer  = 0,
                   typename std::make_unsigned_t<BASIC_TYPE> fraction = 0) noexcept
            : value_{get_init_value(integer, fraction)}
        {
            ...
        }

        ...
        FixedPoint& operator+=(FixedPoint rhs) noexcept
        ...
        FixedPoint& operator-=(FixedPoint rhs) noexcept
        ...
        FixedPoint& operator*=(FixedPoint rhs) noexcept
        ...
        FixedPoint& operator/=(FixedPoint rhs) noexcept
        ...
    private:
        BASIC_TYPE value_;
        ...

        friend bool operator==(FixedPoint lhs, FixedPoint rhs) noexcept
        ...

        // FixedPoint() + intのようなオーバーロードを作るためにあえてfriend
        friend FixedPoint operator+(FixedPoint lhs, FixedPoint rhs) noexcept
        ...
    };

    // @@@ example/programming_convention/fixed_point_ut.cpp 19

    // 以下は、FixedPoint<>の使用例である。
    {
        using FP4 = FixedPoint<uint8_t, 4>;  // 基本型uint8_t、小数点4ビット
        auto fp0  = FP4{};

        ...
        fp0 = 7;    ASSERT_EQ(7, fp0);
        fp0 = 7;    ASSERT_NE(6, fp0);
        fp0 += 2;   ASSERT_EQ(FP4{9}, fp0);         
                    ASSERT_TRUE(is_equal(9.0, fp0.ToFloatPoint()));
        fp0 /= 2;   ASSERT_EQ((FP4{4, 8}), fp0);    
                    ASSERT_TRUE(is_equal(4.5, fp0.ToFloatPoint()));
        fp0 /= 2;   ASSERT_EQ((FP4{2, 4}), fp0);    
                    ASSERT_TRUE(is_equal(2.25, fp0.ToFloatPoint()));
        fp0 *= 4;   ASSERT_EQ(FP4{9}, fp0);
        fp0 += 7;   ASSERT_EQ(FP4{0}, fp0);
    }
    ...
    {
        using FP8 = FixedPoint<int32_t, 8>;  // 基本型int32_t、小数点8ビット

        auto fp0 = FP8{};
        ...
        fp0 = 3;            ASSERT_EQ((FP8{3, 0}), fp0);
        fp0 += 3;           ASSERT_EQ((FP8{6, 0}), fp0);
        fp0 -= 3;           ASSERT_EQ((FP8{3, 0}), fp0);
        ...
        fp0 = 3;
        fp0 *= 5;           ASSERT_EQ((FP8{15, 0}), fp0);
        fp0 /= 5;           ASSERT_EQ((FP8{3, 0}), fp0);
        fp0 = fp0 / 2;      ASSERT_EQ((FP8{1, 0x80}), fp0);
        ...
    }

• 演習-浮動小数点型

3.1.2 enum

• C++の強力な型システムや、コンパイラの静的解析機能(switchでのcase抜け)を効果的に使用するために、 一連の定数の列挙にはenumを使用する。
• 使用範囲や方法が明示しづらく、且つ整数型への算術変換が行われてしまう旧来のenum (非スコープドenum)は、一部の例外を除き定義しない。 代わりに、より型安全なスコープドenumを使用する。

    // @@@ example/programming_convention/type_ut.cpp 133

    enum CarLight { CL_Red, CL_Yellow, CL_Blue };
    enum WalkerLight { WL_Red, WL_Yellow, WL_Blue };

    bool f(CarLight cl) noexcept
    {
        switch (cl) {
        // 非スコープドenumは下記のようなコードを許容する(if文でも同様)。
        // スコープドenumであればこのような間違いはコンパイルエラーで発見できる。
        case WL_Red:  // CL_Regの間違い?
            ...
            break;
        case CL_Yellow:  // これは正しい
        case CL_Blue:
        default:
            ...
            break;
        }

        ...
    }

• 列挙子に値を設定する必要がない場合（具体的な値に意味を持たない場合）には、値を設定しない。 値を設定する場合にはそれらを最初に書き、同じ値を設定しない。

    // @@@ example/programming_convention/type_ut.cpp 163

    enum Colour {   // NG スコープドになっていない。
        Red   = 0,  // NG 配列インデックスでない場合、0を定義する必要はない。
        Green = 1,  // NG 連続値を定義する必要はない。
        Blue  = 2
    };

    ...

    enum class Colour {  // OK
        Red,             // OK 不要な記述がない。
        Green,
        Blue
    };

• enumを配列のインデックスとして使う場合は以下のようにする。
  • スコープドenumの代わりに、旧来のenumをstruct内で定義する。
  • 最初に定義されるenumメンバは0で初期化する。
  • 最後の要素のシンボル名はMaxで終わることにより、 その要素が最大値であることを示す。

    // @@@ example/programming_convention/type_ut.cpp 185

    enum class Foo { FooA = 0, FooB, FooMAX };

    struct Hoo  // structによるスコーピング
    {
        enum {
            HooA = 0,  // OK
            HooB,      // OK 値は暗黙に定義
            HooMAX     // OK
        };
    };

    void f() noexcept
    {
    //  int32_t a0[Foo::FooMAX];                       // NG コンパイルエラー
        int32_t a1[static_cast<size_t>(Foo::FooMAX)];  // NG castが必要になる
        int32_t a2[Hoo::HooMAX];                       // OK
        ...
    }

• enumはC++11から前方宣言できるようになったため、 この機能を使用して、不要なヘッダファイルの依存関係を作らないようにする。

    // @@@ example/programming_convention/type_ut.cpp 211

    enum class IncompleteEnum;
    enum class IncompleteEnum2 : uint64_t;

    // このファイルから可視である範囲にIncompleteEnum、IncompleteEnum2の定義はないが、
    // 前方宣言することで以下の関数宣言をすることができる。
    extern void g(IncompleteEnum);
    extern void g(IncompleteEnum2);

• アプリケーションの設定ファイルに保存された情報を復元させるような場合や、 「BitmaskType」を使用する場合を除き、enumへのキャストをしない。

• クラスのstatic constの整数定数の代わりにenumを使うことは、 C++言語仕様やコンパイラの機能が不十分だった頃のテクニックであり、もはや不要である。 代わりにstatic constexprインスタンス(「constexprインスタンスと関数」参照)を使用する。 こうすることで定数の型を明示できる。

• 演習-定数列挙

• 演習-enum

3.1.3 bit field

• ハードウエアレジスタにアクセスをする目的でのみ使用する。
• bit fieldの型は、unsigned intにする。

3.1.4 class

• 「クラスとインスタンス」を参照せよ。

3.1.5 struct

• メンバ変数を持つ構造体は、PODとしてのみ使用する。
• メンバ変数を持つ構造体を基底クラスとした継承をしない。 従ってそのような構造体は常にfinalであるが、finalの明示はしない。
• メンバ変数(static constやstatic constexprメンバは定数とする)を持たない構造体は、 templateや非スコープドenumのスコーピング(「enum」参照)等に使用しても良い。
• コンストラクタ以外のメンバ関数を定義しない。
  • ディープコピー(「コンストラクタ」参照)が必要な型は、structでなくclassで表す。
  • デフォルトコンストラクタを除く特殊メンバ関数に対して、 = defaultの明示をしない。

    // @@@ example/programming_convention/type_ut.cpp 224

    struct Pod final {                        // NG finalは不要
        Pod()                     = default;  // OK
        ~Pod()                    = default;  // NG = defaultは不要
        Pod(Pod const&)           = delete;   // OK copyを禁止する場合
        Pod operator=(Pod const&) = delete;   // OK copyを禁止する場合

        int32_t x;
        int32_t y;
    };

• Cとシェアしない構造体を無名構造体とそのtypedefで定義しない。

    // @@@ example/programming_convention/type_ut.cpp 237

    typedef struct {  // NG   無名構造体
        int32_t x;
        int32_t y;
    } StructNG;  // NG   無名構造体をtypedef

    typedef struct StructOK_C_Share {  // Cとシェアする場合OK
        int32_t x;
        int32_t y;
    } StructOK_C_Share;

    struct StructOK {  // OK   Cとシェアしない場合このように書く
        int32_t x;
        int32_t y;
    };

3.1.6 union

• ハードウエアレジスタにアクセスをする目的以外で使用しない(以下のような使い方のみ認められる)。

    // @@@ example/programming_convention/type_ut.cpp 258

    union XXX_REG {
        uint8_t  bytes[4];
        uint32_t word32;
    };

    uint8_t f() noexcept
    {
        // 0x14000000はハードウェアレジスタのアドレスとする
        auto& XXX_REG_INST = *reinterpret_cast<XXX_REG*>(0x14000000);
        auto  byte_1       = XXX_REG_INST.bytes[1];

        return byte_1;
    }

• 上記のようなunionはランタイム依存性が強いため、それへの依存を最小にする。 従って、unionの定義を外部パッケージに公開(「パッケージの実装と公開」参照)しない。

• 上記以外でunionのような機能が必要な場合、 std::variant(「std::variantとジェネリックラムダ」参照)を使用する (std::anyはunionの代替えにはならないので、このような場合には使用しない)。

3.1.7 配列

• 配列をnew[]により生成しない。 可変長配列が必要な場合は、std::vectorを使用する(「new」参照)。 固定長配列を動的に確保する場合は、std::arrayをnewする。
• 配列からポインタへの暗黙の型変換をしない(「キャスト、暗黙の型変換」参照)。 特に、オブジェクトの配列をそのオブジェクトの基底クラスへのポインタに代入しないことは重要である (「スライシング」参照)。
• 関数の仮引数を一見、配列に見える型にしない (「実引数/仮引数」参照)。
• char型の配列を文字列リテラルで初期化する場合、配列の長さを指定しない。

    // @@@ example/programming_convention/type_ut.cpp 279

    #if 0
        // g++では通常コンパイルエラーとなるが、-fpermissiveを付ければコンパイルできてしまう。
        char a[3]{"abc"};  // NG aはヌル終端されない
    #else
        char a[]{"abc"};  // OK
    #endif

• 配列の全要素にアクセスするような繰り返し処理には範囲for文を使用する。

• 演習-配列の範囲for文

3.1.8 型エイリアス

• Cとシェアされる型エイリアスを除き、typedefではなくusingを使用する。

    // @@@ example/programming_convention/type_ut.cpp 296

    // C90スタイル
    typedef unsigned int uint;                 // NG
    typedef void (*void_func_int32)(int32_t);  // NG

    ...

    // C++11スタイル
    using uint            = unsigned int;       // OK
    using void_func_int32 = void (*)(int32_t);  // OK

    template <class T>  // templateで型エイリアスを作ることもできる。
    using Dict = std::map<std::string, T>;  // OK

• 型へのポインタのエイリアスは、それを使用してconstポインタが定義できないため、 型へのポインタ(関数ポインタを除く)のエイリアスを作らない。

    // @@@ example/programming_convention/type_ut.cpp 320

    using pint32_t = int32_t*;  // pint32_tにはconstポインタを代入できない。

    pint32_t const pint32_0_c = nullptr;  // 一見pint32_0_cはconstポインタに見えるが。
    int32_t const* pint32_1_c = nullptr;

    // pint32_0_cの型とpint32_1_cの型が同じであれば問題ないのだが、
    // エイリアスのため結合順が変わった影響でそうはならない。
    // *pint32_0_cはconstではなく、pint32_0_cがconstとなる。
    static_assert(std::is_same_v<decltype(pint32_0_c),  int32_t* const>);
    static_assert(std::is_same_v<decltype(*pint32_0_c), int32_t&>);
    static_assert(std::is_same_v<decltype(pint32_1_c),  int32_t const*>);
    static_assert(std::is_same_v<decltype(*pint32_1_c), int32_t const&>);

• 演習-エイリアス

3.1.9 const/constexprインスタンス

• インスタンス、インスタンスへのポインタ、インスタンスへのリファレンス等に対して、
  • constexpr(「constexprインスタンスと関数」参照)にできる場合、constexprにする。
  • constexprにはできないが、const(「constインスタンス」にはできる場合、constにする。 関数の仮引数になっているリファレンスやポインタをconstにすることは特に重要である (「実引数/仮引数」、「三項演算子」参照)。
  • 文字列リテラルのアドレスを非constポインタ型変数に代入しない(「リテラル」参照)。
  • イテレータにおいても、可能な場合は、イテレータをconstするか、const_iteratorを使う。

    // @@@ example/programming_convention/type_const_ut.cpp 13

    // name0は文字列リテラルを指すポインタなのでconstでなければならない。
    char const* name0 = "hoge";

    // name1は文字列リテラルでないのでconstでなくてよい。
    char name1[] = "hoge";

    char const* get_str();
    // 左側のconstはname2の指す先をconstにする。
    // 右側のconstはname2自体をconstにする。
    char const* const name2 = get_str();

    // name2の右辺がリテラルならば、下記のようにするべきである。
    constexpr char const* name3 = "hoge";

    void f(std::vector<int32_t>& vec)
    {
        std::vector<int32_t>::iterator const iter = vec.begin();  // iter自体がconst

        *iter = 10;
        // ++iter;      // 意図的にコンパイルエラー

        std::vector<int32_t>::const_iterator const_iter_0 = vec.begin();   // *const_iter_0がconst
        auto                                 const_iter_1 = vec.cbegin();  // *const_iter_1がconst
        static_assert(std::is_same_v<std::vector<int32_t>::const_iterator, decltype(const_iter_1)>);

        // *const_iter_0 = 10;   // 意図的にコンパイルエラー
        ++const_iter_0;

        // *const_iter_1 = 10;   // 意図的にコンパイルエラー
        ++const_iter_1;

        ...
    }

• constは、意味が変わらない範囲で出来るだけ右側に書く。

    // @@@ example/programming_convention/type_const_ut.cpp 52

    const std::string s;  // NG
    std::string const t;  // OK

    const std::string* s_ptr;  // NG
    std::string const* t_ptr;  // OK

    const std::string& f();  // NG 関数の宣言
    std::string const& g();  // OK 関数の宣言

    char        abc[]{"abc"};
    const char* a = abc;  // NG *aはconst
    char const* b = abc;  // OK *aはconst
    char* const c = abc;  // NG *aではなく、aがconstになり、意味が変わる

    const char* const d = abc;  // NG
    char const* const e = abc;  // OK

• 演習-constの意味
• 演習-const/constexpr

3.1.10 リテラル

• ヌルポインタを表すポインタリテラルとして、nullptrを使用する(0やNULLを使用しない)。

    // @@@ example/programming_convention/type_ut.cpp 343

    int32_t* a{0};        // NG   オールドスタイル
    int32_t* b{NULL};     // NG   C90の書き方
    int32_t* c{nullptr};  // OK   C++11

    // @@@ example/programming_convention/type_ut.cpp 362

    extern int g(long a) noexcept;
    extern int g(int* a) noexcept;

    // NULLを使ったことで、わかりづらいバグが発生する例
    g(NULL);  // NG NULLはポインタではないため、この呼び出しはg(long)を呼び出す
    static_assert(std::is_same_v<long, decltype(NULL)>);

    g(nullptr);  // OK 意図通り、g(int*)を呼び出す。
    static_assert(std::is_same_v<std::nullptr_t, decltype(nullptr)>);

• 文字列リテラル(“xxx”)はconstオブジェクトとして扱う (「const/constexprインスタンス」、「std::string型リテラル」参照)。
• 長い汎整数型リテラルを使用する場合は、適切に区切りを入れる(C++14)。
• ビットマスク等2進数を使用した方が直感的な場合には2進数リテラルを使用する(C++14)。

    // @@@ example/programming_convention/type_ut.cpp 384

    auto a = 123'456'789U;       // = 123456789
    auto b = 0x123'456'789U;     // = 0x123456789
    auto c = 0b1001'0001'0101U;  // = 0x915

• bool型を表すリテラルにはtrue、falseを使用する。代わりに0、1、!0等を使わない。

    // @@@ example/programming_convention/type_ut.cpp 395

    bool a{0};          // NG
    bool b{!0};         // NG
    bool c{false};      // OK
    auto d = bool{0};   // NG
    auto e = bool{!0};  // NG
    auto f = true;      // OK

• long値リテラルを表す文字には”l”ではなく、“L”を使う。

    // @@@ example/programming_convention/type_ut.cpp 408

    auto a = 432l;  // NG 4321と区別が難しい
    auto b = 432L;  // OK

• 演習-危険なconst_cast
• 演習-リテラル

3.1.11 型推論

3.1.11.1 auto

• AAAスタイルに従い適切にautoを使用する。

    // @@@ example/programming_convention/type_ut.cpp 422

    void f(std::vector<std::string> const& strs)
    {
        auto s0 = std::string{"hehe"};  // OK
        auto s1{std::string{"hehe"}};   // OKだが、通常は代入を使用する
        auto s2 = s0;                   // OK
        auto s3 = get_name();           // NG get_name()の戻り値を見ないとs3の型が不明

        for (auto const& str : strs) {  // OK strsの型が明らかであるため、strの型も明らか
            ...
        }
    }

• autoを使用する場合、&、*、const等の付け忘れに注意する。

    // @@@ example/programming_convention/type_ut.cpp 442

    class A {
    public:
        A() = default;

    #if 0  // NG この関数を呼び出すとクラッシュ
        std::string const& Get(char first_byte) const noexcept
        {
            static std::string const empty;
            for (auto const str : strs) {       // NG &の付け忘れのため、スタック上の
                if (str.at(0) == first_byte) {  //    オブジェクトのリファレンスをreturnする。
                    return str;
                }
            }
            return empty;
        }

    #else  // OK 上のGetの修正。
        std::string const& Get(char first_byte) const noexcept
        {
            static std::string const empty;
            for (auto const& str : strs) {      // OK &を付けて、インスタンスのオブジェクトの
                if (str.at(0) == first_byte) {  //    リファレンスを返せるようになった。
                    return str;
                }
            }
            return empty;
        }
    #endif

    private:
        std::vector<std::string> strs{"aha", "ihi", "uhu"};
    };

• autoと= {}を使用した変数の宣言には以下のような紛らわしさがあるため、 そのような記述を行わない(「インスタンスの初期化」参照)。

    // @@@ example/programming_convention/type_ut.cpp 493

    auto a = 1;       // OK aの型はint
    auto b(1);        // 別の規制でNG ()より{}を優先的に使うべき
    auto c{1};        // OK cの型はint
    auto d = {1};     // NG dの型はstd::initializer_list<int>
    auto e = {1, 2};  // NG eの型はstd::initializer_list<int>
    auto f = std::initializer_list<int>{1, 2};  // OK

    static_assert(std::is_same_v<decltype(a), int>, "type not same");
    static_assert(std::is_same_v<decltype(b), int>, "type not same");
    static_assert(std::is_same_v<decltype(c), int>, "type not same");
    static_assert(std::is_same_v<decltype(d), std::initializer_list<int>>, "type not same");
    static_assert(std::is_same_v<decltype(e), std::initializer_list<int>>, "type not same");
    static_assert(std::is_same_v<decltype(f), std::initializer_list<int>>, "type not same");

• auto、decltype, decltype(auto)の微妙な違いに気を付ける。

    // @@@ example/programming_convention/type_ut.cpp 515

    short  s0{0};
    short& s0_ref{s0};

    {  // autoとdecltypeが同じ動作をするパターン
        auto a = s0;
        static_assert(std::is_same_v<decltype(a), short>);

        decltype(s0) d = s0;
        static_assert(std::is_same_v<decltype(d), short>);

        decltype(auto) da = s0;
        static_assert(std::is_same_v<decltype(da), short>);
    }
    {  // autoとdecltypeに違いが出るパターン
        auto a = s0_ref;
        static_assert(std::is_same_v<decltype(a), short>);

        decltype(s0_ref) d = s0_ref;  // dはリファレンス
        static_assert(std::is_same_v<decltype(d), short&>);

        decltype(auto) da = s0_ref;  // daはリファレンス
        static_assert(std::is_same_v<decltype(da), short&>);
    }

    short s1{0};
    {  // 微妙な違いで出るパターン
        auto a = s0 + s1;
        static_assert(std::is_same_v<decltype(a), int>);

        decltype(s0) d = s0 + s1;  // これが意図的ならよいが
        static_assert(std::is_same_v<decltype(d), short>);

        decltype(s0 + s1) d2 = s0 + s1;  // int&&にはならない
        static_assert(std::is_same_v<decltype(d2), int>);

        decltype(auto) da = s0 + s1;  // この方がクローンがないため上よりも良い
        static_assert(std::is_same_v<decltype(da), int>);
    }

• 演習-適切なautoの使い方

3.1.12 インスタンスの初期化

• 関数内のオブジェクトは、出来る限りAAAスタイルを用いて宣言し、同時に初期化する。
• 算術型の宣言にAAAスタイルが使えない場合、 「代入演算子を伴わない一様初期化」を使用する。 「代入演算子を伴う一様初期化」、「()、=による初期化」を使用しない。

    // @@@ example/programming_convention/type_ut.cpp 572

    int32_t a0(0);            // NG
    int32_t a1 = 0;           // NG
    int32_t a2{0};            // OK 一様初期化
    int32_t a3 = {0};         // NG 代入演算子を伴う一様初期化
    auto    a4 = 0;           // OK AAAの場合は一様初期を使わなくても問題ない
    auto    a5 = int32_t{0};  // OK AAA且つ一様初期

• リファレンスやポインタの宣言にAAAスタイルが使えない場合、 「代入演算子を伴わない一様初期化」か「=による初期化」を使用する。 「代入演算子を伴う一様初期化」、「()による初期化」を使用しない。

    // @@@ example/programming_convention/type_ut.cpp 581

    int32_t& r0(a0);     // NG
    int32_t& r1 = a0;    // OK
    int32_t& r2{a0};     // OK 一様初期化
    int32_t& r3 = {a0};  // NG 代入演算子を伴う一様初期化
    auto&    r4 = a0;  // OK AAAの場合は一様初期を使わなくても問題ないが、&の付け忘れに気を付ける

    int32_t* p0(&a0);     // NG
    int32_t* p1 = &a0;    // OK
    int32_t* p2{&a0};     // OK 一様初期化
    int32_t* p3 = {&a0};  // NG 代入演算子を伴う一様初期化
    auto     p4 = &a0;    // OK AAAの場合は一様初期を使わなくても問題ない
    auto*    p5 = &a0;    // OK AAAの場合は一様初期を使わなくても問題ない

• 構造体やクラス型オブジェクトの宣言にAAAスタイルが使えない場合、
  • 「代入演算子を伴わない一様初期化」を使用する。
  • 上記では意図したコンストラクタが呼び出せない場合にのみ「()による初期化」を使用する。 ただし、std::string、std::string_viewに関しては「 = “xxx”」を使用しても良い。

    // @@@ example/programming_convention/type_ut.cpp 609

    // 構造体の初期化
    struct Struct {
        int32_t     a;
        char const* str;
    };

    Struct s0{1, "1"};           // OK 代入演算子を伴わない一様初期化
    Struct s1 = {2, "2"};        // NG 代入演算子による一様初期化
    Struct s2{};                 // OK s2.aは0、s2.strはnullptrに初期化される。
    Struct s3;                   // NG s3は未初期化
    auto   s4 = Struct{1, "1"};  // OK AAAスタイル
    auto   s5 = Struct{};        // OK AAAスタイル

    // クラスの初期化
    std::unique_ptr<Widget> a{std::make_unique<Widget>()};   // OK
    std::unique_ptr<Widget> b(std::make_unique<Widget>());   // NG {}を使うべき
    auto                    c{std::make_unique<Widget>()};   // OK
    auto                    d = std::make_unique<Widget>();  // OK
    // このような場合、重複を避けるため、変数宣言の型はautoが良い

    // std::string、std::string_viewの初期化
    std::string str0{"222"};     // OK
    std::string str1 = {"222"};  // NG = は不要
    std::string str2("222");     // NG {}で初期化できない時のみ、()を使う。
    std::string str3(3, '2');    // OK {}では初期化できない。str3 == "222"
    std::string str4 = "222";    // OK 例外的に認める
    auto        str5 = std::string{"222"};  // OK AAAスタイル

    std::string_view sv0 = "222";                    // OK 例外的に認める
    auto             sv1 = std::string_view{"222"};  // OK AAAスタイル

    // {}、()による初期化の違い
    std::vector<int32_t> vec0_i{1, 2, 3};  // OK vec0_i.size() == 3 && vec0_i[0] == 1 ...
    std::vector<int32_t> vec1_i{10};       // OK vec1_i.size() == 1 && vec1_i[0] == 10
    std::vector<int32_t> vec2_i(10);       // OK vec1_i.size() == 10
    auto                 vec3_i = std::vector{1, 2, 3};  // OK vec0_iと同じ

    std::vector<std::string> vec1_s{10};  // OK vec1_s.size() == 10
    std::vector<std::string> vec2_s(10);  // NG vec2_s.size() == 10  {}を優先するべき
    auto                     vec3_s = std::vector<std::string>{10};  // OK vec1_sと同じ

    // vec1_i、vec2_i、vec1_sの初期化は似ているが、結果は全く異なる。
    // vec1_iは、vector(initializer_list<>)を呼び出す。
    // vec2_iは、vector(int)を呼び出す。
    // vec1_sは、vector(int)を呼び出す。

    ASSERT_EQ(3, vec0_i.size());
    ASSERT_EQ(1, vec1_i.size());
    ASSERT_EQ(10, vec2_i.size());
    ASSERT_EQ(vec0_i, vec3_i);
    ASSERT_EQ(10, vec1_s.size());  // vec1_iと同じ形式で初期化したが結果は全く異なる。
    ASSERT_EQ(10, vec2_s.size());
    ASSERT_EQ(10, vec3_s.size());

• decltypeによるオブジェクトの宣言は、AAAスタイルと同様に行う。

    // @@@ example/programming_convention/type_ut.cpp 677

    auto  a = 0;
    auto& b = a;

    decltype(a)    c = a;    // OKがautoの方が良い
    decltype(a)    d = {a};  // NG
    decltype(b)    e = a;    // OK
    decltype(auto) f = b;    // OK

    static_assert(std::is_same_v<decltype(c), int>);
    static_assert(std::is_same_v<decltype(d), int>);
    static_assert(std::is_same_v<decltype(e), int&>);
    static_assert(std::is_same_v<decltype(f), int&>);

• 配列の宣言には、「代入演算子を伴わない一様初期化」を使用する。 char[]に関しては、「代入演算子を伴わない一様初期化」か「 = “xxx”」を使用する。

    // @@@ example/programming_convention/type_ut.cpp 700

    int32_t array0[3]{1, 2, 3};     // OK 代入演算子を伴わない一様初期化
    int32_t array1[3] = {1, 2, 3};  // NG 代入演算子による一様初期化
    int32_t array2[3]{};            // OK 代入演算子を伴わない一様初期化
    int32_t array3[3] = {};         // NG 代入演算子による一様初期化

    char c_str0[]{'1', '2', '\0'};     // OKだが、非推奨
    char c_str1[] = {'1', '2', '\0'};  // NG 代入演算子による一様初期化
    char c_str2[] = {"12"};            // NG 代入演算子による一様初期化
    char c_str3[]{"12"};               // OK
    char c_str4[] = "12";              // OK

• 宣言時にポインタ変数の初期値が決まらない場合、nullptrで初期化する(「リテラル」参照)。

    // @@@ example/programming_convention/type_ut.cpp 723

    int32_t*       ptr1 = nullptr;  // OK
    int32_t*       ptr2{nullptr};   // OK
    char const*    pchar0 = 0;      // NG
    char*          pchar1 = NULL;   // NG
    int32_t const* ptr0(nullptr);   // NG {}か=で初期化する

• 初期化順序が不定になるため、 別のコンパイル単位で定義された静的なオブジェクトに依存した静的オブジェクトの初期化を行わない (同じファイルの上方にある静的なオブジェクトや、 Singletonに依存した初期化を行うことには問題はない)。
• コンパイル時に値が確定する「基本型」や「コンストラクタがconstexprであるクラス」のインスタンスは、 constexpr(「const/constexprインスタンス」参照)と宣言する。

    // @@@ example/programming_convention/type_ut.cpp 735

    constexpr int32_t f_constexpr(int32_t a) noexcept { return a * 3; }
    int32_t           f_normal(int32_t a) noexcept { return a * 3; }

    // @@@ example/programming_convention/type_ut.cpp 743

    constexpr auto a = f_constexpr(3);  // OK
    auto const     b = f_constexpr(3);  // NG constexprにできる
    // constexpr auto c = f_normal(3);  // NG コンパイルエラー
    auto const d = f_normal(3);  // OK

• constなオブジェクトが複雑な初期化を必要とする場合、その初期化にはラムダ式を使用する。

    // @@@ example/programming_convention/type_ut.cpp 756

    int32_t len{10};  // ここではlenは固定だが、関数引数等で外部から与えられるとする

    auto vc0 = std::vector<int32_t>(len);  // vc0が初期化以外で変更されないのであれば、NG
    std::iota(vc0.begin(), vc0.end(), 1);  // vc0の初期化

    auto const vc1 = [len]() {  // OK vc1の初期化
        std::vector<int32_t> ret(len);
        std::iota(ret.begin(), ret.end(), 1);
        return ret;
    }();  // ラムダ式の生成と呼び出し

• 演習-インスタンスの初期化
• 演習-vector初期化
• 演習-ポインタの初期化

3.1.13 rvalue

• 関数の仮引数以外のリファレンスでrvalueをバインドしない (「オブジェクトのライフタイム」参照)。
• rvalueの内部ハンドルを使用しない(「std::string_viewの使用制限」参照)。

    // @@@ example/programming_convention/type_ut.cpp 790

    char const* str = std::string{"str"}.c_str();
    // strが指すポインタはこの行では解放済

    ASSERT_STREQ(str, "str");  //    strは無効なポインタを保持であるため、未定義動作

• 非constなリファレンスでrvalueをバインドしない。

3.2 クラスとインスタンス

3.2.1 ファイルの使用方法

• 下記の例外を除き、一つのクラスはそれを宣言、定義する1つのヘッダファイルと、 一つの.cppファイルによって構成する。
  • ファイル外部から使用されないクラスは、一つの.cppファイルの無名名前空間で宣言、定義する。
  • ファイル外部から使用されるインラインクラス(クラステンプレート等)は、 一つのヘッダファイルで宣言、定義する。
  • 「一つのヘッダファイル(a.h)と、一つの.cpp(a.cpp)で構成されたクラスA」のみをサポートするクラス (Aのインターフェースや実装専用に定義されたクラス(「Pimpl」参照))は、 a.h、a.cppで宣言、定義する。

3.2.2 クラスの規模

3.2.2.1 行数

• それ以外に方法がない場合を除き、ヘッダファイル内のクラスの定義、 宣言はコメントを含め200行程度に収める。
• クラス内定義関数が大きくなると下記のような問題が発生しやすくなるため、 10行を超える関数はクラス内で定義しない。
  • 関数のインポートする外部シンボルが多くなり、 このクラスを使用する別のクラスに不要な依存関係を作ってしまう (「インターフェース分離の原則(ISP)」参照)。
  • クラスの定義が間延びして、クラスの全体構造を把握することが困難になる。

3.2.2.2 メンバの数

• それ以外に方法がない場合を除き、publicメンバ関数の数は、最大7個程度に収める (ただし、オーバーロードにより同じ名前を持つ関数群は、全部で1個とカウントする)。
• オブジェクトの状態を保持するメンバ変数の数は、最大4個程度に留める。 constやconstexprメンバ・インスタンスは定数(状態を保持するメンバ変数ではない)であるため、 この数に含めない。

3.2.2.3 凝集度

• 単なるデータホルダー(アプリケーションの設定データを保持するようなクラス等)や、 ほとんどの振る舞いを他のクラスに委譲するようなクラスを除き、 凝集度が高くなるように設計する。

• 演習-凝集度の意味

• 演習-凝集度の向上

3.2.3 アクセスレベルと隠蔽化

• アクセスレベルは、特別な理由がない限り、上からpublic、protected、privateの順番で明示する。

    // @@@ example/programming_convention/class_ut.cpp 12

    class A {
        void f0();  // NG デフォルト private を使用しない。
    public:
        void f1();  // OK
    private:
        void f2();  // OK
    protected:
        void f3();  // NG privateの前に定義すべき。
    };

• 全てのメンバ変数はprivateにする。
  • メンバ変数にアクセスしたい場合は、Accessorメンバ関数を経由させる (「Accessor」参照)。その場合でもsetterは控えめに使用する。
  • 派生クラスから基底クラスの変数の値が必要になる場合は、protectedなAccessorを定義する。
  • 単体テスト用クラスでは、protectedメンバ変数を定義してよい。
• アクセスレベルによるカプセル化が破壊されるため、 メンバ変数のハンドル(リファレンスやポインタ)を返さない。 それが避けがたい場合においては、constハンドルを返す。

    // @@@ example/programming_convention/class_ut.cpp 28

    class B {
    public:
        ...

        void* f0() noexcept  // NG メンバ変数が保持するポインタを返している
        {
            return v_ptr_;
        }

        std::string* f1() noexcept  // NG メンバ変数へのポインタを返している
        {
            return &str_;
        }

        std::string& f2() noexcept  // NG メンバ変数へのリファレンスを返している
        {
            return str_;
        }

        std::string f3() const noexcept  // OK ただし、パフォーマンスに注意
        {
            return str_;
        }

        std::string const& f4() const noexcept  // OK
        {
            return str_;
        }

    private:
        void*       v_ptr_ = nullptr;
        std::string str_{};
    };

• 以下のような場合を除き、friendを使用しない。
  • 単体テスト用クラス
  • 二項演算子をオーバーロードした関数

    // @@@ example/programming_convention/class_ut.cpp 68

    class Integer {
    public:
        Integer(int32_t integer) noexcept : integer_{integer} {}

        // メンバ関数に見えるが、非メンバ関数
        friend bool operator==(Integer lhs, Integer rhs) noexcept  // OK
        {
            return lhs.integer_ == rhs.integer_;
        }

    private:
        int32_t const integer_;
    };

    bool operator!=(Integer lhs, Integer rhs) noexcept { return !(lhs == rhs); }

• NVI(non virtual interface)に従う。従って、 virtualな関数はprivateかprotectedと宣言し、それをpublicな非仮想メンバ関数から呼び出す。

    // @@@ example/programming_convention/class_ut.cpp 86

    class Widget {
    public:
        virtual int32_t DoSomething() noexcept  // NG virtualでpublic
        {
            ...
        }

        int32_t DoSomething(bool b) noexcept  // OK non-virtualでpublic
        {
            return do_something(b);
        }
        ...
    private:
        virtual int32_t do_something(bool b) noexcept  // OK virtualでprivate
        {
            ...
        }
        ...
    };

3.2.4 継承/派生

• 派生は最大2回程度までに留める。やむを得ず階層が深くなる場合、 コードの静的解析等を使用し派生関係を明確にする(「クラスのレイアウト」参照)。
• 実装の継承よりも、包含、委譲を優先的に使用する。やむを得ず実装の継承を行う場合は、 private継承を使用する。 実装の継承をしたクラスがfinalでないならば、protected継承を使用する (CRTP(curiously recurring template pattern)等は例外的に認められる)。

    // @@@ example/programming_convention/class_ut.cpp 124

    // private継承。非推奨
    class StringWrapper0 final : private std::string {
    public:
        explicit StringWrapper0(char const* str) : std::string{str} {}

        void AddStr(char const* str) { *this += str; }

        using std::string::c_str;
    };

    // 移譲。こちらを優先する
    class StringWrapper1 final {
    public:
        explicit StringWrapper1(char const* str) : str_{str} {}

        void AddStr(char const* str) { str_ += str; }

        char const* c_str() const noexcept { return str_.c_str(); }

    private:
        std::string str_;
    };

• 派生させないクラスは、finalと宣言する。ほとんどのクラスは派生しないはずなので、 ほとんどのクラスはfinalになる。
• リソースリークの原因になり得るため、非virtualなデストラクタをもつクラスを継承しない。 ただし、継承したクラスが基底クラスのメンバ変数以外のメンバ変数を持たないならば、継承しても良い。

    // @@@ example/programming_convention/class_ut.cpp 149

    class A {  // デストラクタの呼び出しチェック用のクラス
    public:
        A(bool& destructed) noexcept : destructed_{destructed} { destructed_ = false; }
        ~A() { destructed_ = true; }

    private:
        bool& destructed_;
    };

    class BaseNG {  // NG デストラクタが非virtual
    public:
        BaseNG() = default;
    };

    class DerivedNG : public BaseNG {
    public:
        DerivedNG(bool& destructed) : a_{std::make_unique<A>(destructed)} {}

    private:
        std::unique_ptr<A> a_;
    };

    // @@@ example/programming_convention/class_ut.cpp 183

    auto a_destructed = false;
    {
        std::unique_ptr<DerivedNG> d{std::make_unique<DerivedNG>(a_destructed)};
        ASSERT_FALSE(a_destructed);
    }
    ASSERT_TRUE(a_destructed);  // OK A::~A()が呼ばれたため問題ないが、、、

    {
        std::unique_ptr<BaseNG> d{std::make_unique<DerivedNG>(a_destructed)};
        ASSERT_FALSE(a_destructed);
    }
    ASSERT_FALSE(a_destructed);  // NG A::~A()が呼ばれないため、メモリリークする

    // @@@ example/programming_convention/class_ut.cpp 201

    class BaseOK {  // OK デストラクタがvirtual
    public:
        BaseOK()          = default;
        virtual ~BaseOK() = default;
    };

    class DerivedOK : public BaseOK {
    public:
        DerivedOK(bool& destructed) : a_{std::make_unique<A>(destructed)} {}

    private:
        std::unique_ptr<A> a_;
    };

    // @@@ example/programming_convention/class_ut.cpp 221

    auto a_destructed = false;
    {
        std::unique_ptr<DerivedOK> d{std::make_unique<DerivedOK>(a_destructed)};
        ASSERT_FALSE(a_destructed);
    }
    ASSERT_TRUE(a_destructed);  // OK A::~A()が呼ばれたため問題ない

    {
        std::unique_ptr<BaseOK> d{std::make_unique<DerivedOK>(a_destructed)};
        ASSERT_FALSE(a_destructed);
    }
    ASSERT_TRUE(a_destructed);  // OK A::~A()が呼ばれたため問題ない

3.2.4.1 インターフェースの継承

• クラス間に「Is-a」の関係が成り立つときに限りpublic継承を行う。
  • public継承を行う場合、リスコフの置換原則(LSP)を守る。
  • インターフェースを継承しない場合、public継承をしない。
• C#やJavaのinterfaceが必要ならば(インタフェースと実装の完全分離をしたい場合等)、 pure-virtualなメンバ関数のみを宣言したクラス (もしくはそのクラスにNVI(non virtual interface)を適用したクラス) を定義する。

3.2.4.2 多重継承

• それが不可避でない限り、多重継承は使用しない。
• 多重継承を使用する場合、複数個の基底クラスのうち、一つを除きメンバ変数を持ってはならない。
• 多重継承を使用する場合、継承階層内に同じ基底クラスが複数回出てきてはならない (ダイヤモンド継承をしない)。
• やむを得ずダイヤモンド継承をせざるを得ない場合、 継承階層内に複数回出現する基底クラスにはvirtual継承を行う。
• virtual継承を行ったクラスのコンストラクタからは、 virtual基底クラスのコンストラクタを呼び出すようにする (こうしないとvirtual基底クラスは初期化されない)。

3.2.5 非静的なメンバ変数/定数の初期化

• [定義] 非静的なメンバ変数の初期化には下記の3つの方法がある。
  • 初期化方法０: 非静的メンバ変数の初期化子による初期化(NSDMI)
  • 初期化方法１: コンストラクタの非静的メンバ初期化子による初期化
  • 初期化方法２: コンストラクタ内での非静的なメンバ変数の初期値の代入

    // @@@ example/programming_convention/class_ut.cpp 243

    class A0 {
    public:
        A0() noexcept : b_{0}    // 初期化方法１
        {
            c_ = 0;     // 初期化方法２
        }

    private:
        int32_t a_{0}; // 初期化方法０
        int32_t b_;
        int32_t c_;
    };

• [注意] 初期化方法０と、初期化方法１が同一変数に行われた場合、初期化方法０は実行されない。
• すべての非静的なメンバ変数は、コンストラクタ終了時までに明示的に初期化する。
• 多くのコンパイラや静的解析ツールは、 初期化方法０、１による初期化の漏れについては容易に発見、指摘できるが、 初期化方法２による初期化の漏れについては、発見が難しい場合がある。 また、constメンバ変数は、初期化方法２では初期化できないため、 それ以外に方法がない場合を除き、初期化方法２の使用を避ける。
• 非静的なメンバ変数はクラス内で定義された順序に従い初期化されるため、 初期化方法１で羅列される初期化の順序を定義順序と同じにする (初期化方法１での初期化の順序は、実際の初期化の順序とは関係がない)。

    // @@@ example/programming_convention/class_ut.cpp 262

    class A_NG {
    public:
        A_NG(int32_t x, int32_t y) noexcept
            : b_{x + y}, a_{x}, c_{y} // NG メンバ変数定義と初期化の順序が違う
        {
        }

    private:
        int32_t a_;
        int32_t b_;
        int32_t c_;
    };

    class A_OK {
    public:
        A_OK(int32_t x, int32_t y) noexcept : a_{x}, b_{x + y}, c_{x}  // OK
        {
        }

    private:
        int32_t a_;
        int32_t b_;
        int32_t c_;
    };

• クラスがただ一つのコンストラクタを持つ場合、初期化方法０と初期化方法１を混在させない。 従って、初期化方法１を必要とするメンバ変数が一つでもある場合は、 すべての変数の初期化を初期化方法１で行う。

    // @@@ example/programming_convention/class_ut.cpp 291

    class A1 {
    public:
        A1() noexcept {}  // OK 初期化方法０に統一

    private:
        int32_t const a_{1};  // OK 初期化方法０による初期化。
                              //    ただし、static constexprにすべき。
        int32_t b_[2]{0, 1};  // OK 初期化方法０による初期化
        int32_t c_{5};        // OK 初期化方法０による初期化
    };

    class A2 {
    public:
        explicit A2(int a) noexcept   // OK 初期化方法１に統一
            : a_{a}, b_{0, 1}, c_{5}  // OK 初期化方法１による初期化
        {
        }

    private:
        int32_t const a_;
        int32_t       b_[2];
        int32_t       c_;
    };

    class A3 {
    public:
        explicit A3(int a) noexcept : a_{a}  // NG 初期化方法の混在
        {
            c_ = 5;  // NG 初期化方法０、１使用可能にもかかわらず初期化方法２を使用している
        }

    private:
        int32_t const a_;
        int32_t       b_[2]{0, 1};  // NG 初期化方法の混在
        int32_t       c_;
    };